-
-
Notifications
You must be signed in to change notification settings - Fork 427
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
feat: add fixture that fails to resolve to _index.import.scss #905
Conversation
I see, give me some time to debug sass resolution, it is easy to fix |
I am afraid we can't fix it, because /cc @nex3 We returned again to the old problem, which you absolutely do not want to fix |
@bgotink My recommendation don't use |
@alexander-akait If you return |
@nex3 yep, looks good like workaround |
@nex3 oh, no, I can't, developer can write I really can't understand - no new API for resolving and no actions on current problems and bugs |
Just note - |
If you just resolve the directory and use the same base filename that the user passed in, the Sass compiler will automatically do the rest of the resolution for you. You don't need to care about whether the path has |
@nex3 I can't do it
Because when I run |
@nex3 I'm already ready to beg you to listen to us, currently sass-loader code it is hacky code with ton of workarounds, just to let the resolving system work (webpack + sass), all i need to reduce complex and improve performance - it is |
All of that is fine—just return |
It will work but it require a lot of extra logic and it reduces perf very, if you want to have best perf, we need information about it was |
What extra logic does it require? I'm essentially suggesting that you ignore the existence of |
@nex3 we need simulate sass logic, because webpack has aliases/fallbacks/etc mechanisms, also developer can write |
All of those aliases and fallbacks should happen prior to resolving the import-only file. If the user aliases Writing |
@nex3 But we don't know real filename, developers can use |
After you pass |
What about if |
If someone explicitly aliases |
@nex3 it is the problem, because I don't know what is user provide, resolver can be configured in different ways, it supports plugins too, above you told me that I should just delete |
I'm not saying you should ever remove |
@nex3 I am not adding anything, this value from
|
This is the part I don't understand. An importer that returns file paths should never need to manually look for |
We do not do this and we have this problem (described above). We have |
Okay, let me see if I'm understanding correctly:
|
@nex3 and other case:
|
@nex3 friendly ping |
Finally found time to circle back to this. I'm planning to add a |
This will allow me to write a fast-track proposal to add metadata about whether a load is coming from `@import` or not, to address webpack-contrib/sass-loader#905.
Yes, it will help 👍 Maybe we can do it better |
We don't plan to add any new modes of loading files that don't re-use module semantics for a long, long time if ever. Also, I think listing |
It was just an idea, maybe using |
This will allow me to write a fast-track proposal to add metadata about whether a load is coming from `@import` or not, to address webpack-contrib/sass-loader#905.
This is a fast-track proposal. See webpack-contrib/sass-loader#905
This is a fast-track proposal. See webpack-contrib/sass-loader#905
This will allow me to write a fast-track proposal to add metadata about whether a load is coming from `@import` or not, to address webpack-contrib/sass-loader#905.
This is a fast-track proposal. See webpack-contrib/sass-loader#905
This PR contains a:
Motivation / Use-Case
The resolution of .import.scss files in sass-loader differs from the resolution of sass itself. (#904)
While creating the reproduction I noticed everything works fine if I add a
_index.scss
file next to the_index.import.scss
file.That being said, in our case we have files we explicitly only want to expose to
@import
and not to@use
, so we have files that only exist with the.import.scss
extension. This works with relative imports in sass but not when using~
imports via sass-loader.Adding an extra file without the
.import
in the filename—e.g., a file that contains an@error
to fail when loaded—is a pretty clean workaround. We'll use that, though it would of course be great if we could skip that.The error while running the tests: