-
-
Notifications
You must be signed in to change notification settings - Fork 601
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
Cannot @import "bar.scss" when the extension is not .css (4.0.0 regression) #1164
Comments
Fixes webpack-contrib#1164. Signed-off-by: Anders Kaseorg <[email protected]>
css-loader@^4 is also available, but we can’t use it yet because of webpack-contrib/css-loader#1164. Signed-off-by: Anders Kaseorg <[email protected]>
css-loader@^4 is also available, but we can’t use it yet because of webpack-contrib/css-loader#1164. Signed-off-by: Anders Kaseorg <[email protected]>
css-loader@^4 is also available, but we can’t use it yet because of webpack-contrib/css-loader#1164. Signed-off-by: Anders Kaseorg <[email protected]>
This comment has been minimized.
This comment has been minimized.
Yes, it is expected, I recommended refactor code and avoid it, without restrictions you can import JS file, one of the reasons why ES modules require extensions |
I’m confused by this response…surely you aren’t recommending that all Webpack users abandon Sass, SCSS, Less, Stylus, PostCSS merely because “it is weird”? If not, how would you like this to be solved? Note that my proposed patch does not allow |
css-loader@^4 is also available, but we can’t use it yet because of webpack-contrib/css-loader#1164. Signed-off-by: Anders Kaseorg <[email protected]>
Where I say it? I recommend do not use
|
I’m not mixing CSS and SCSS; this is about importing {
loader: "css-loader",
options: {
importLoaders: 1,
sourceMap: true,
},
},
{
loader: "postcss-loader",
options: {
sourceMap: true,
},
}, with PostCSS using the /* postcss.config.js */
module.exports = ({file}) => ({
parser: file.extname === ".scss" ? "postcss-scss" : false,
plugins: {
"postcss-nested": {},
"postcss-extend-rule": {},
"postcss-simple-vars": {},
"postcss-calc": {},
autoprefixer: {},
},
}); Perhaps this is different from a typical
In what way would |
Please create reproducible test repo, restriction for |
You should not use |
// webpack.config.js
module.exports = {
mode: "development",
entry: "./foo.scss",
module: {
rules: [
{
test: /\.scss$/,
use: [
"style-loader",
{ loader: "css-loader", options: { importLoaders: 1 } },
"postcss-loader",
],
},
],
},
}; // postcss.config.js
module.exports = {
parser: "postcss-scss",
plugins: [
// not important for this self-contained example
],
}; /* foo.scss */
@import "bar.scss"; /* bar.scss */
html {
background: red;
} npm i webpack webpack-cli style-loader postcss-loader postcss-scss css-loader
npx webpack (If you want to look at the real-world code that ran into this, it’s https://github.com/zulip/zulip/blob/master/tools/webpack.config.ts.) |
Your configuration mix CSS and SCSS |
Also using |
I still don’t understand how an example with exactly one If what you’re saying is that no
I don’t see any documentation suggesting that |
Because
No, you can still use
Again ignore me.
Most of plugins for postcss designed for pure CSS, not for sass/scss, so I as written above I don't think we should document it here.
You can create an own loader, if you have non standard approaches. Sorry it is limitation, if you want to use |
You can't use |
And again:
From your config you try to imitate Sass-like syntax, so you should not use |
You never asked me to test it in the browser…all you said was “if you try to use it in browser, it was broken”. We both know how browsers work. Browsers do not care about file extensions. If the browser sees an That’s all I’m asking of
Huh? I’ve given you two self-contained reproducible test cases (one, two) and one full real-world project. Is your complaint that I gave you the test files in the form of code blocks rather than in the form of a literal Git repository?
This alleged restriction isn’t documented anywhere. The But okay, if SCSS must be processed with // webpack.config.js
module.exports = {
mode: "development",
entry: "./foo.scss",
module: {
rules: [
{
test: /\.scss$/,
use: [
"style-loader",
{ loader: "css-loader", options: { importLoaders: 1 } },
"sass-loader",
],
},
],
},
}; // foo.scss
@import "bar.scss" (min-width: 992px); // bar.scss
html {
background: red;
}
|
No, it is worked on MIME type, otherwise it will be not safe From chome: For JS:
For png:
Yes, you can setup web server to send
one - I write you - it is expected and it is limitation
Ok, but how does this relate to this problem?
Just note - non JS never supported by webpack, it is feature for webpack@5, yes it worked in most of cases, but I warn you that this can be broken or lead to errors, this was not in the design for webpack@4 Because you mix CSS and SCSS again. // foo.scss
@import "bar.scss" (min-width: 992px); compiling to @import "bar.scss" (min-width: 992px); |
If you give me a link to the repository, I will give you my recommendations on how to properly organize it. You can take them into account if you wish. The main problem is that you mix |
css-loader@4 broke @import statements referencing files with extensions other than .css, unless those @import statements are compiled away by another loader. Upstream is more interested in arguing that such @import statements are semantically incorrect than applying the one line fix. webpack-contrib/css-loader#1164 Signed-off-by: Anders Kaseorg <[email protected]>
css-loader@4 broke @import statements referencing files with extensions other than .css, unless those @import statements are compiled away by another loader. Upstream is more interested in arguing that such @import statements are semantically incorrect than applying the one line fix. webpack-contrib/css-loader#1164 Signed-off-by: Anders Kaseorg <[email protected]>
css-loader@4 broke @import statements referencing files with extensions other than .css, unless those @import statements are compiled away by another loader. Upstream is more interested in arguing that such @import statements are semantically incorrect than applying the one line fix. webpack-contrib/css-loader#1164 Signed-off-by: Anders Kaseorg <[email protected]>
css-loader
≥ 4.0.0 givesError: Can't resolve 'bar.scss'
when I try to@import "bar.scss"
. It works when the extension is.css
but not when it’s.scss
. I bisected this to commit edf5347 (#1099). The problem is triggered by therestrictions: [/\.css$/i]
setting that was hard-coded here:css-loader/src/index.js
Lines 50 to 56 in edf5347
Expected Behavior
With css-loader 3.6.0:
Actual Behavior
With css-loader ≥ 4.0.0:
Code
How Do We Reproduce?
Create the three files above and run
npm i webpack webpack-cli css-loader; npx webpack
.The text was updated successfully, but these errors were encountered: