SassError: Can't find stylesheet to import when it contains @forward with _index file #804
Comments
|
|
Looks like something broken on |
|
Also let's run: node_modules/.bin/dart-sass --load-path=node_modules fixture-use.scssAll work and fine. But: node_modules/.bin/dart-sass --load-path=node_modules fixture-import.scssNo output and no errors |
|
/cc @nex3 Looks something broken on |
|
Example without const sass = require('sass');
const result = sass.renderSync({
file: './fixture-use.scss',
// file: './fixture-import.scss',
includePaths: ['node_modules'],
importer: function(url, prev, done) {
console.log(url);
}
});
console.log(result.css.toString());For For |
|
Thanks for looking into this @evilebottnawi Though the resolved url points to the base url for some stylesheets, for example I've updated my code example. |
Both of these invocations print the same output for me with the latest version of @abhiomkar's repo. I think this is a legit sass-loader bug. |
|
@nex3 No, please run again and look at result, latest I wouldn’t like to spend time studying dart and looking for issues, so I ask you to take a little more responsibility, thanks |
|
The URLs are expected to be different between |
|
@nex3 Where I can found documentation about that? I can't found |
|
And please stop saying that there are bugs everywhere except your code, we are both developers and may make a mistake in our code, so I prefer to investigate firstly and then say where the problem is. Thanks |
|
I'm sorry, I didn't mean to cast blame—I only meant to explain why you were seeing that output. @abhiomkar and I were actually initially investigating Dart Sass for a bug here before we ended up determining it was more likely a sass-loader issue and filing this. The module system is informally documented on the Sass website. The section on imports and modules is particularly relevant here, since it describes how import-only files work. For more detailed information, you can check out the Sass specification, particularly the sections on modules and |
- Add usage for MDC Sass modules to getting started guide - Add density mixin examples - Switch `highlight.js` theme to `scss/github` - Temporary workaround for webpack-contrib/sass-loader#804 - Load code samples from url - Refactor and improve performance of template page component - Update component documentation closes #2038
|
I did some investigation to see how the URLs are resolved. I'm not very familiar with how webpack importer works but seems like resolve() function in webpackImporter is resolving the url to Workaround for now is to disable module.exports = {
mode: 'development',
entry: './fixture-import.scss',
module: {
rules: [
{
test: /\.s[ac]ss$/i,
use: [
'css-loader',
{
loader: 'sass-loader',
options: {
+ webpackImporter: false,
sassOptions: {
includePaths: ['node_modules'],
},
implementation: require('dart-sass'),
},
},
],
},
],
},
};@evilebottnawi Hope this helps debug the issue :) |
|
Based upon @abhiomkar investigation I checked how webpack resolves files and came to this conclusion. Webpack only tries to check for the specified extensions only if it doesn't find any valid package.json field based on the mainField option. What we need to fix this issue is one simple line to enforce the required extensions. Google material has javascript files as as the main entrypoint in their package.json. The option is probably https://webpack.js.org/configuration/resolve/#resolveenforceextension . The thing is the documentation that webpack provides is wrong? This option does not enforce requires to have an extension (or does it?) but enforces the resolution to use the extensions options. I confirmed this fact right here: https://github.com/webpack/enhanced-resolve#resolver-options . It clearly states that it is doing exactly what we want "Enforce that a extension from extensions must be used". |
ghost
mentioned this issue
…S format Includes a workaround for Webpack not loading @use declarations correctly: webpack-contrib/sass-loader#804 (comment)
|
@abhiomkar Do we have a known solution for app using Create React App (without ejecting) ? |
|
I will work on that fix tomorrow |
We can't support this case, because I'll try to repeat it again 😞 : We have package.json {
"scss": "other.scss"
}index.scss $color: red;
a {
color: $color;
}other.scss $color: blue;
a {
color: $color;
}And we have this in our file: *style.scss @import 'package'; If you run pure $color: red;
a {
color: $color;
}But if you run $color: blue;
a {
color: $color;
}Why? Because I know you ask again why not just pass
We should give preference to Another example: Then we do (with @import 'color-utils'; If you run pure
@nex3
I can explain it easily - most |
I totally understand that Webpack supports more resolution capabilities than Sass on its own. That's natural and expected. The point I'm making is that the question you want to ask, "Can you resolve it or not?", is not affected by import-only files.
I understand why you can't return But if you do return the latter result, import-only files will automatically work without any need for extra logic in In other words, the importer still gets to do all its Webpack-specific logic and pop out whichever result would be correct for
I'm having trouble understanding this. What's the problem if
You say that
If all you're looking for is prioritizing plain-Sass import path resolution above custom importers, that's something that will almost certainly be possible as part of sass/sass#2509. |
|
@nex3 Tired 😞 , I’ve been trying to show you a design error for several months now and you’re not doing anything, I support many webpack packages integrated with many different tools, I do not want to show myself smarter than someone else, but I have enough knowledge to show all integrations problems. And you repeat the same thing several times, completely refusing to understand me. I think you need help from another I deeply cannot understand why What is the problem to implement
THE PROBLEMSNumber 1
We run Lastly you even have Number 2
We run Number 3
We run Why do these problems exist?From source:
We need to emulate logic for everything below
What am I supposed to do here? Do you suggest me to start implementation and design? Just say that you don’t want to fix it and save my and your time, it’s not so difficult. I'll just embed the modified |
|
I think I do understand you. In all of your examples, it seems like you're saying that you want Sass's I also think that this isn't that big of a problem in the short-term. The issues you point out are all pretty narrow situations with ambiguous Across all Sass implementations since custom importers were first introduced, they've always taken precedence over the user's load paths. I understand this isn't what users want 100% of the time, but it is frequently what they want and I don't think it's particularly surprising behavior.
Sass has a strong design process which precludes adding new APIs just because they're useful in the short term. Just tossing together whatever APIs more or less work is why the current importer API is such a mess in the first place. If and when we add new features, we need them to be well-thought-out and thoroughly integrated into the way Sass thinks about things. The reason On the other hand, it does make sense to say "put
You're a major stakeholder in the importer API and you have strong opinions about how it should look, so certainly it's reasonable for you to contribute to the design. I believe @Awjin is also working on some design work here, so perhaps you and he can collaborate. |
|
@evilebottnawi it looks like you and @nex3 were able to land on the root of your problem. I agree that the following behavior will be useful to have in the new API:
Would this be an acceptable/useful solution for |
|
@nex3 Good, then what are our actions in the short term? I do not want to leave it in current state. Developers have a problems and these problems annoy them, no matter how good sass has design process. It is real problem and we need to solve it for our developers. What are your suggestions? And unfortunately, we most likely cannot solve it without new API or new options. Another idea
I don't think I have enough time on this, My task is very simple, as you understand it - ability to run |
|
Fixed in v9 https://github.com/webpack-contrib/sass-loader/releases/tag/v9.0.0 with some hacks, unfortunately, this can lead to loss of performance in some rare cases, we can do nothing here, hope The algorithm was improved and tested very well, but I'm still worried about some rare cases when we can do something wrong. So feel free to open a new issue with minimum reproducible test repo if you faced with problems, we will fix it. |
-------------------------- The sass-loader package v9 has important bug fixes for issues described at webpack-contrib/sass-loader#804
But what about people who don't use Webpack? For my project I use Stencil builder! |
|
@rutwick-alic Seriously? |
I fail to understand if you're being sarcastic or asking me genuinely. But yeah, Stencil doesn't necessarily require Webpack. |
|
@rutwick-alic, this issue and repository has nothing to do with your support request, try asking your question on the Slack channel of Stencil: https://stencil-worldwide.herokuapp.com |
Fixes SassError: Can't find stylesheet to import. @import "@material/base/mixins"; @see webpack-contrib/sass-loader#804
|
I had the same issue on using both mdc snackbar and banner So I thought if it is an error with webpack blah de blah and |
Expected Behavior
Expected
sass-loaderto resolve the module when_index.scssfiles are used.Actual Behavior
sass-loaderthrows following error when@import'ed Sass file contain@forwardstatement with _index file. (See reproducible steps below).Code
See complete example here:
https://github.com/abhiomkar/sass-module-bug
How Do We Reproduce?
Notice the error:
Changing webpack entry file
fixture-import.scss=>fixture-use.scsswould fix the error.UPDATE: See this comment for temporary workaround.
The text was updated successfully, but these errors were encountered: