-
-
Notifications
You must be signed in to change notification settings - Fork 470
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
1.1.2 injects the same stylesheet more than once #450
Comments
It is expected, you have two
It is required for right order, for example you can include on
Without double including we break css |
For example, you have: index.html <!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta name="description" content="" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Webpack Playground</title>
<style>
@import url('./order-1.css');
@import url(http://example.com/style.css);
@import url('./order-2.css');
@import url(http://example.com/style.css);
@import url('./order-1.css');
@import url(http://example.com/style.css);
@import url('./order-2.css') screen and (min-width: 2000px);
@import url(http://example.com/style.css);
div {
width: 100%;
height: 200px;
}
</style>
</head>
<body>
<h1>Webpack Playground</h1>
<p>Text</p>
<div> Text of DIV </div>
</body>
</html> order-1.css div {
background: red;
} order-2.css div {
background: blue;
} recreate that example and look in dev tools, each |
Yes, it was changed because before it was invalid, downgrade loader with example above and you will see what color invalid. |
I see. May there be a sense in keeping only the last include, as it overrides all the previous ones anyway? UPD: I mean, last include for each unique pair of resource + media query |
Actually, changed order is what led me to discovering this issue. E.g., if you add this to .bar {
color: red;
}
|
It is potential unsafe and broke how
Right, it’s good that you found this problem, the same styles may seem like a mistake, but this is the correct insertion algorithm, I can spend time and provide you with examples when the previous algorithm broke the import logic, yes it increases the page size a bit, but we should use the correct logic instead of a small reduction and potential invalid order which again can lead to the wrong style |
In my case it ruins everything. I am using Something like that: common.css: .common {
background-color: yellow;
} 1.css: .selector1 {
composes: common from 'common.css';
background-color: red;
} 2.css: .selector2 {
composes: common from 'common.css';
background-color: navy;
} import css1 from './1.css'
import css1 from './2.css'
css1.use();
css2.use();
const el1 = document.createElement('div');
document.body.appendChild(el1);
el1.className = styles1.locals.selector1
const el2 = document.createElement('div');
document.body.appendChild(el2);
el2.className = styles2.locals.selector2 And now we will have <style>
.common { background-color: yellow; }
</style>
<style>
.selector1 { background-color: red; }
</style>
<style>
.common { background-color: yellow; }
</style>
<style>
.selector2 { background-color: navy; }
</style> Second common style has override |
@evilebottnawi I have the same issue due to using CSS Modules |
Yep, it is bug, looking for the solution |
Problem what css |
I think that makes sense. 😄 |
What about |
|
I'm asking because in our codebase, we mostly import a classname as
|
pretty bug Need to wait until this issue is resolved before updating this: webpack-contrib/style-loader#450 Not a big deal, only took me 2 hours to figure out what's going wrong here. The day we completely move to `styled-components` can't come any sooner...
* Upgrade deps. * Add `request` dependency explicitly. Not sure how this used to work, but now webpack is throwing that it can't find this dependency so we're installing it explicitly. * Fix ambiguous composition in css modules. Not sure how this used to work, but now it throws an error. * Update `css-loader` options. * Import `upload` function only in Electron environment. Reverts commit fbfb355. Previously, I thought it was some library that's requiring the `fs` module, and it turns out it was me after all. Oops. * On second thought, rever the `style-loader` dependency as it has a pretty bug Need to wait until this issue is resolved before updating this: webpack-contrib/style-loader#450 Not a big deal, only took me 2 hours to figure out what's going wrong here. The day we completely move to `styled-components` can't come any sooner... * Update deprecated Electron APIs. * Fix prettier lint errors. * Add a temporary fix for overriding default button styles. * Import Electron `screen` API from the main process.
I found solution, I can not be in time because of the holidays (but I will try to make it in time ), I really apologize |
@evilebottnawi thank you for your hard work! Enjoy the holidays! |
I'm not sure how the old behavior was incorrect, It looks wrong when you write normal css imports but that's not the expected behavior of modules or the dependencies in webpack. In general we usually assume that a required module is only imported the first time as is the case with JS. It's impossible now for dependency order to be correct for css files that depend on each other. Consider this case without base-button.css .btn {
height: 30px;
} custom-button.css .custom-btn {
height: 60px;
} toolbar.css @value btn from './base-button.css';
.toolbar > btn {
margin-left: 10px
} CustomButton.js
Toolbar.js
App.js
My expectation, and previous behavior is that CustomButton has overriden the base button height, b/c it was defined later. But not b/c SomeComponent imports after Custom Button it re imports the style. I know this has been covered but i wanted to make the case that this is NOT just a css-modules issue, it also vastly increases the number of styles that included in the app during dev :/ |
I guess all i'm saying is, trying to match the css import spec seems lik the wrong thing to do, at least as a default. I don't think it's possible for css to interoperate with js in the way webpack has defined without it treating css imports with the same rules as the rest of the dependency graph |
@jquense Imports from JS seem to work as they did before: https://github.com/Hypnosphi/style-loader-duplicates/tree/import-from-js |
Hmm interesting! I'm definitely not seeing that, maybe i can turn it into a repro, |
O i see, yeah the trigger is css-modules, BUT in our case it's absolutely due to a EDIT updated my example with breaking case PS: @evilebottnawi this change also breaks my approach in the css-module-loader proof of concept, since it adds PPS: I also found a bug in the pre |
@evilebottnawi does it make sense to have an additional concept in css-loader that marks things as dependencies but not css imports? TBH it seems strange that I guess this is really highlighting that css-loader should really not do css-modules as well. |
@jquense it is bug, i will fix it in near future, there was a vacation and I unfortunately did not have time, sorry |
no worries, i've realized i'm in the same boat for old versions as well. Please don't rush, enjoy vacation. |
Partial fixed, but some cases still broken (it was broken in previous versions too):
|
Please test https://github.com/webpack-contrib/style-loader/releases/tag/v1.1.3 and put feedback here, should be work fine in 99% cases |
My case #450 (comment) looks like is solved. Will test it additionally. Thank U! |
Thanks @evilebottnawi. It mostly works, but not in a case when B composes from A, and C composes from both A and B. I updated https://github.com/Hypnosphi/style-loader-duplicates to reproduce this case. |
@Hypnosphi please update |
I can confirm that it's fixed with |
Let's keep open for some other edge case (#450 (comment)), I think I will fix it in next week, anyway thanks for the issue |
Im using scss modules, getting duplicate inline css with these versions "style-loader": "1.2.1" or "1.1.3" Repo for reproducing the issue here: https://github.com/nicomfe/ultimate-react-server-rendering/tree/with-redux-and-scss-modules |
All problems should be resolved, if you faced with the proble - please open a new issue and I will help |
Expected Behavior
Each stylesheet gets injected only once
Actual Behavior
Stylesheet gets re-injected each time it's imported from another stylesheet
How Do We Reproduce?
https://github.com/Hypnosphi/style-loader-duplicates
yarn && yarn start
Open http://localhost:8080, inspect the HTML:
It doesn't reproduce with
1.0.2
, see1.0
branchThe text was updated successfully, but these errors were encountered: