3 ms·

> Built-in tsconfig paths support A great QoL change. One less place to duplicate (and potentially mistake) a config.

• c-hendricks 7mo ago
  This is great news, but people should also try using regular nodejs import aliases and see if they're viable for their project.
  • Timon3 7mo ago
    I keep trying the "native" solutions every so often, but every time I quickly hit some snag that makes me question why I'm not just using the solution that actually works. As an example, I just generated a new project using create-vite & added two subpath imports: { // ... "imports": { "#assets/*": "./src/assets/*", "#/*": "./src/*" }, // ... } The second one (#/*) is similar enough to what I usually use (@/*), and it's supported in Node since v25.4.0! Yet when I try to import the file at projectRoot/src/router/index.ts using: import router from "#/router/index" VS Code shows an error: "Cannot find module '#/router/index' or its corresponding type declarations." Now, imports from e.g. "#assets/main.css" work, so I could work around this issue - but this is what I keep experiencing: the native variant usually kinda works except for the most common use case, which is made unnecessarily awkward. For a long time this is what ESM used to feel like, and IMO it still does in places (e.g. directory imports not working is a shame).
    • arkon_hn 7mo ago
      You need Typescript 6 for that too: https://devblogs.microsoft.com/typescript/announcing-typescript-6-0-rc/#subpath-imports-starting-with-#/ https://devblogs.microsoft.com/typescript/announcing-typescr...
    • c-hendricks 7mo ago
      I'm confused myself. I have one project that uses package json aliased imports and TS doesn't complain. Then another where it does.