css-loader
css-loader copied to clipboard
url resolutions for tilde prefixes fail with pnpm's isolated dependencies
Bug report
When using pnpm's default isolated dependencies installation mode, dependencies are not necessarily reachable from the originating stylesheet's directory, and instead need to be resolved from where they originated. This is mainly an issue with the sass-loader, which inlines all referenced URLs as though they occur in the source sass file.
Actual Behavior
Suppose you have the following file structure:
.
└── node_modules
└── foo
├── hello.scss
└── node_modules
└── bar
└── example.svg
hello.scss
has a url('~bar/example.svg')
which is now unresolvable for any importer of hello.scss
. In short, the issue is that the css-loader expects a flat node_modules where everything is hoisted, but pnpm specifically does not do this.
Expected Behavior
I think there are two options:
- Provide a way for users to define a query string parameter in the
url('...')
statement that the loader will use as the context when resolving any given URL. A sass importer could then be contributed back to the sass-loader which rewrites URLs with the appropriate context embedded in URLs. - Leverage the same algorithm used by the resolve-url-loader (or enhance that loader) to leverage sourcemaps for determining what the context is for any given URL.
How Do We Reproduce?
Please see the explanation above for an example layout that causes this issue.
Please paste the results of npx webpack-cli info
here, and mention other relevant information
Sorry, not related to css loader, it was dicussed a lot of time, please ask developers to provide variables to set path(s) to assets (for example bootstrap and tialwind do it), also you can use alias
/roots
/fallback
and other resolver
option to fix it, there are a lot of various technicians too, you can write a custom loader, also ~
is deprecated and should be not used (except very exotic cases)
If you provide an example where you have problems I can help you to setup it and we can improve our docs so other developers will not have such problems
As far as I know aliases can’t be set dynamically in one loader then passed to another, can they? If that’s the case then maybe I can use an importer on the sass side to pass that along to the css loader.
As far as I know aliases can’t be set dynamically in one loader then passed to another, can they?
No, you need to list all of them, but you need it, can you provide a real use case?
If that’s the case then maybe I can use an importer on the sass side to pass that along to the css loader.
We pass loader context in sass-loader to importer so - yes, you can use it, you even create own resolver with own logic and resolve whatever you want, but the main question - why a lot of heavy code if you just set alias
/fallback
or ask developers to add variables for assets (or fork a project if it is old and add required logic)