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

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

Open
sgarfinkel opened this issue Mar 23, 2023 · 3 comments
Open

Comments

@sgarfinkel
Copy link

sgarfinkel commented Mar 23, 2023

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 sgarfinkel changed the title URL and Import resolutions for tilde prefixes fail with pnpm's isolated dependencies @url and @import resolutions for tilde prefixes fail with pnpm's isolated dependencies Mar 24, 2023
@sgarfinkel sgarfinkel changed the title @url and @import resolutions for tilde prefixes fail with pnpm's isolated dependencies url resolutions for tilde prefixes fail with pnpm's isolated dependencies Mar 24, 2023
@alexander-akait
Copy link
Member

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

@sgarfinkel
Copy link
Author

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.

@alexander-akait
Copy link
Member

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants