-
-
Notifications
You must be signed in to change notification settings - Fork 389
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
Control import order when importing with multiple rules #562
Comments
@evilebottnawi thanks for taking a look. I could be wrong, but I don't think this is a duplicate. In my head, this is a different use case. The two issues you referenced are about the import order of multiple css-modules compared to themselves. What I'm looking for is the ability to write to the output file the entire css-module chunk AFTER the non-css-module chunk. Maybe I'm missing something but I couldn't find another similar issue that referenced a config file that shows two rules using |
Please clarify |
@evilebottnawi I think the config file in the original post provides the most clarity, and to try and simplify further, in both of these webpack configs... rules: [
{
// Test for CSS-MODULES
// Use MiniCssExtractPlugin.loader
},
{
// Test for NON-module css
// Use MiniCssExtractPlugin.loader
},
] and (order reversed) rules: [
{
// Test for NON-module css
// Use MiniCssExtractPlugin.loader
},
{
// Test for CSS-MODULES
// Use MiniCssExtractPlugin.loader
},
] ... the output css file will be ... // All CSS-MODULES css
// ...
// All NON-module css My hope is to have a way for non-module css to be above the css-modules, since the former is all boilerplate and vendors and should be easy to override with equal specificity css in the css-modules. |
I still can't understand the problem? Why do you need this? Order of rules should not affect on something, you can event simplify you config with latest |
@evilebottnawi Right, order of rules has no effect on output. So using rules: [
{
test: /\.css$/,
loader: [
MiniCssExtractPlugin.loader,
{
loader: 'css-loader',
options: {
modules: {
auto: /modules.*\.css$/,
},
},
},
],
}
] The issue is still the same. The output css file first has "module-css", followed by "non-module" css. WhyI have a React app. In any component I use global (non-module) css along with component specific (module) css. If I have a component that looks like this: import styles from './component.modules.css`;
...
<div className={`label ${styles.specificLabel}`}>
Headline
</div> And css that looks like this: /* global.css */
.label {
color: red;
width: 100%;
}
/* component.modules.css */
.specificLabel {
width: 50%;
} The div would be /* output.css */
.specificLabel {
width: 50%;
}
.label {
color: red;
width: 100%;
} Sorry if this is a weird use case but I feel like my setup is at least somewhat common - using both css-modules and non-module css in conjunction. It's common to occasionally want to override a boilerplate style with something that's specific to a component and being able to control which chunk is written out first would be advantageous. |
Yes, you have invalid order of css modules, it should be fixed on app side, maybe you can create simple case with repo and I will provide examples how you can solve it |
@evilebottnawi well that was exhausting, but I figured out what was going on in my setup and "order" is the right answer. In my React SPA I import the full app into a root index file which looks something like this: import App from '$containers/App';
import '$scss/global.css';
...
render((
<App />
), document.getElementById('root')); Since The fix is obviously... import '$scss/global.css';
import App from '$containers/App';
...
render((
<App />
), document.getElementById('root')); Additional infoIn my case, the problem was accentuated because of using webpack.config // (BAD - don't use)
{
// Import container and component index.scss as local CSS Modules
test: /\.scss$/,
include: /(components|containers).*\.scss$/,
loader: [
isDevelopment ? 'style-loader' : MiniCssExtractPlugin.loader,
{
loader: 'css-loader',
options: {
modules: {
localIdentName: `${isDevelopment ? '[local]___' : ''}[hash:base64:5]`,
},
sourceMap: isDevelopment,
},
},
{
loader: 'sass-loader',
options: {
sourceMap: isDevelopment,
},
},
],
},
{
// Import all other scss as global
test: /\.scss$/,
exclude: /(components|containers).*\.scss$/,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'sass-loader',
],
}, This is terribly obvious in hindsight, but somehow all the comments in other threads about "fixing your order" didn't help me much. Thanks @evilebottnawi for your timely responses. |
Expected Behavior / Situation
When using mini-css-extract-plugin to import both module css and non-module css, it would be great to be able to control the order of the css in the output file. I would prefer the output file to have all the css in my non-module css files followed by the css in all the esModule files.
Actual Behavior / Situation
The loader seems to always first load module css files, followed by non-module css files, no matter their order in the config file. This is an issue because my non-module css contain a bunch of boilerplate styles and vendors like Bootstrap and I would like to be able to override them easily.
In order to override them, I would have to add more specificity (or
!important
) to my module styles. For example:In this example, since
general.css
is always imported AFTERcomponent.css
, the resultingcolor
will bered
.Here is the basic configuration:
Modification Proposal
I'm not sure I've accurately identified the problem (that css-modules are always imported first), but if it is correct, I think something like an
importOrder
option could work?I believe this has been brought up in a number of places, though many comments seem to be related to fixing the import order in the css files themselves, which I don't think is the issue. Here are some of those that I think are related:
https://stackoverflow.com/questions/57487324/how-can-i-control-the-order-of-css-with-minicssextractplugin
#188
Note that as documented in issue 188, this is especially problematic when using
style-loader
in development, because it effectively reverses the import order and leads to a potential disparity in production.The text was updated successfully, but these errors were encountered: