Add support for Node.js Subpath Imports

[in-in]

Is your feature request related to a problem? Please describe.
I tried using Subpath imports but they don't work. It would be great if it were possible to use native way no configure paths.

Describe the solution you'd like
Subpath imports should work the same way as aliases from tsconfig.json work now.

Describe alternatives you've considered
I don't know any alternatives for Subpath imports

Additional context
Article: https://betterprogramming.pub/the-native-way-to-configure-path-aliases-in-frontend-projects-5db70f19a6e0
Docs: https://nodejs.org/api/packages.html#subpath-imports

Now the plugin works in two cases:
relative path import styles from "../styles/Home.module.css";

alias from tsconfig.json import styles from "@/styles/Home.module.css";

But if you use subpath imports you get an error:
import styles from "#styles/Home.module.css";

[stefan-dasbach-lumi]

Can we get an update on this @mrmckeb?

[Guihgo]

not working with libraries installed at node_modules too.

npm install foo_bar_library
import style from "foo_bar_library/style.module.css"

[mrmckeb]

Hi all, this seems like a fairly simple thing to implement. We should probably look at supporting "exports" too at some stage.

Is anyone interested in creating a PR to support this? If not, I can probably make time in the next week or two.

[mrmckeb]

@Guihgo I think you have a different issue. Can you please raise a new issue with a reproduction? This plugin definitely works with installed packages, and we have tests covering that.

[porteneuve]

Hey all! We actually get similar issues here when trying to @use in-npm-package paths exposed by their exports field, as these are ESM packages. The plugin refuses to read these and requires actual FS paths within the module, which is incorrect and would, actually, break bundling / actual usage.

It seems the resolution system of the plugin doesn't properly use imports/exports resolution (like TS's NodeNext / Bundler moduleResolution settings), when it definitely should. Will try and figure out a fix and offer a PR.

[porteneuve]

After digging into this quite a bit, it appears that the issue is not with how resolveModuleNameLiterals is invoked (it does carry our TS Config's moduleResolution and module settings, which are appropriate (e.g. bundler resolution).

I do see in the TS Server log stylesheet-level resolution errors though:

Err 68    [16:23:11.181] Can't find stylesheet to import.
  ╷
1 │ @import '@mycompany/design-system/style/focus';
  │         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  ╵
  src/App.module.scss 1:9  root stylesheet

This stylesheet builds fine (OOB Vite / PostCSS / SASS), but the plugin somehow configures either SASS or PostCSS in a way that does not honor ESM imports / exports field, as the /style/focus subpath is an export specifier (the actual FS-based subpath is dist/style/focus, which the plugin does resolve, but that won't build because it doesn't match any export specifiers, and the rest of the tooling honors ESM semantics properly).

I couldn't quite place where in src/index.ts we configure either PostCSS or SASS in a way that breaks that kind of resolution. The "Can't find stylesheet to import." error message only occurs in sass/sass.dart.js, by the way.

This seems like the same root cause as #275, FWIW

At any rate this is a significant source of friction for us, as the rest of the company can't access mixins exposed by our design system now, at least not in a way that doesn't yell at them IDE-wise when this plugin is enabled :(