search

webpack-contrib / sass-loader

Compiles Sass to CSS
MIT License
3.91k stars 430 forks source link

Avoid using `#` for Sass loads #1205

Closed nex3 closed 4 months ago

nex3 commented 4 months ago

Related to https://github.com/sass/dart-sass/issues/1635, it sounds like in some cases the WebPack importer suggests that users use the # in Sass imports. Because Sass imports are URLs and # is already meaningful in URLs as the fragment indicator, this is semantically overloaded.

Because per the URL spec defines the fragment as "either null or an ASCII string that can be used for further processing on the resource the URL’s other components identify", we should really not be treating stylesheets with the same canonical URL but different fragments as distinct resources, and possibly we shouldn't be allowing fragments in Sass URLs at all. As we consider moving to a more accurate and spec-compliant handling of URLs (https://github.com/sass/sass/issues/3882), it's a good idea for the WebPack importer to encourage users to avoid using them to resolve distinct files.

alexander-akait commented 4 months ago

We don't recommend to use #, it is a part of NodeJS spec, more precisely this is the import field specification - https://nodejs.org/api/packages.html#imports, so I can't fix it here, even more I don't think it is possible to stop using it, maybe sass can impove it and handle some cases when @import/@use starts with # (like we do in our resolver), sorry I can't say developers don't use it, feel free to feedback

nex3 commented 4 months ago

The Node.js specification for how imports are resolved is specific to JavaScript imports—there's no intrinsic reason that that should also apply to Sass URLs. I understand that the WebPack importer tries to match Node.js syntax as much as possible, but there are always going to be cases where Node's idioms just aren't compatible with Sass's, or with URLs in general. (For example, you already can't use ./ to distinguish relative loads since in a URL context ./foo and foo are equivalent.)

We're probably going to move forward with deprecating and eventually removing support for fragments in module URLs. Whether you prefigure that or not is up to you, but I strongly recommend it.