-
Notifications
You must be signed in to change notification settings - Fork 347
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
NodePackageImporter support for subpaths entry points without extensions #2183
Comments
Good catch, and thanks for the repro! It should be supported- in adding handling for the variants ( That should be a straightforward fix. In the meantime, changing node_modules/@stuff/tokens/dist/colors.scss:1 Debug: colors file |
I know I already approved #3793, but thinking about it... is this behavior desirable? Or is this an issue with the documentation? Although Node.js does allow extensionless export specifiers for JS, they seem to encourage writing the extension. And because Sass will do extension resolution automatically on the export map, there's not necessarily a strong reason to allow both here. |
I considered that, but I do think there's a case to be made for extensionless export specifiers. One of the motivations behind using conditional exports is to allow different types of exports for a path based on what is importing the path. Most of the time, that's going to be One concrete use case would be a component library that exposes a
We could potentially require a wildcard in the export key like
|
But if using extensions is more idiomatic, wouldn't the better way to represent that be {
"exports": {
"./card.scss": {
"sass": "./src/scss/_card.scss",
},
"./card.js": {
"default": "./src/js/components/card.js",
},
}
} ...since Node generally encourages users to write I also think this may be easier to explain to users as "the exports field is a virtual filesystem that the importer looks at to load files" rather than "the exports field maps to the string in your URL, except that it also does a bunch of extra resolution like a filesystem, but unlike a filesystem it supports extensionless basenames". |
I think the exports can be considered to be very similar to symlinks. For a symlink, we would just load it at its location at face value, and don't really actually care about its realpath, that the symlink itself do need an extension, but realpath does not matter. |
I think the tension here is that this conflicts with Sass, which generally encourages I do agree that treating the exports field strictly as a virtual filesystem would be simpler, but we are already doing some extra resolution in the exports that differs from how Sass resolves on the filesystem with the default export. On a filesystem, the analogous concept would be an index file, but in exports, we resolve As far as Node recommendations vs practice, a few instances I found-
In my mind, it is surprising for "mypkg/card" not to resolve the specifier |
You're probably right that this is easier to just allow than not since the parallel with JS is somewhat ambiguous. I do think we should update our documentation to exclusively show examples with explicit extensions, though. |
Fixed by #2184. |
Greetings,
if we refer to the
NodePackageImporter
documentation at https://sass-lang.com/documentation/js-api/classes/nodepackageimporter, it should be possible to use subpaths entry points such as@use "pkg:uicomponents/colors";
with exports declared as:I've tried every combination possible but couldn't make it work.
I get the following error:
sass.Exception [Error]: Can't find stylesheet to import.
Here is a repro: https://github.com/pascalduez/sass-node-pkg-importer-repro
In fact, we can't find this precise case covered in the specs:
https://github.com/sass/sass-spec/blob/66778689d32c5559c399f910732e923f25574963/js-api-spec/node-package-importer.node.test.ts
Is it really supported?
Thanks!
The text was updated successfully, but these errors were encountered: