css-loader icon indicating copy to clipboard operation
css-loader copied to clipboard

url resolutions for tilde prefixes fail with pnpm's isolated dependencies

Open sgarfinkel opened this issue 1 year ago • 3 comments

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:

  1. 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.
  2. 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

sgarfinkel avatar Mar 23 '23 17:03 sgarfinkel

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

alexander-akait avatar Mar 24 '23 17:03 alexander-akait

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.

sgarfinkel avatar Mar 24 '23 18:03 sgarfinkel

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)

alexander-akait avatar Mar 27 '23 16:03 alexander-akait