Avoid using `#` for Sass loads
nex3 opened this issue · comments
Related to sass/dart-sass#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 (sass/sass#3882), it's a good idea for the WebPack importer to encourage users to avoid using them to resolve distinct files.
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
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.