Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Node.js Subpath Imports #263

Open
in-in opened this issue Mar 26, 2024 · 6 comments
Open

Add support for Node.js Subpath Imports #263

in-in opened this issue Mar 26, 2024 · 6 comments
Labels
enhancement New feature or request good first issue Good for newcomers
Milestone

Comments

@in-in
Copy link

in-in commented Mar 26, 2024

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";

24086110815

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

24086111007

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

24086111142

@stefan-dasbach-lumi
Copy link

Can we get an update on this @mrmckeb?

@Guihgo
Copy link

Guihgo commented Sep 29, 2024

not working with libraries installed at node_modules too.

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

@mrmckeb
Copy link
Owner

mrmckeb commented Oct 10, 2024

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
Copy link
Owner

mrmckeb commented Oct 10, 2024

@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.

@mrmckeb mrmckeb added enhancement New feature or request good first issue Good for newcomers labels Oct 10, 2024
@mrmckeb mrmckeb added this to the v6.0.0 milestone Oct 10, 2024
@porteneuve
Copy link

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
Copy link

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 :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

5 participants