-
-
Notifications
You must be signed in to change notification settings - Fork 8.7k
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
CSS Order Differs Between Development & Production Modes when Treeshaking. #7094
Comments
Yeah we could improve this. (But technically using sideEffects you say order doesn't matter). Note to myself: for "index" we use dependency order, but for harmony execution harmony initi oder should be respected. |
Thanks for the reply.
I'm curious why this is the case. Is it a technical limitation? For me, the final order doesn't matter, but what does matter is a consistent order between development and production environments |
@brycehill are you saying that unused CSS which causes the development mode to look different from production mode is getting treeshaken? |
@TheLarkInn That's what I thought was happening at first. However, if you take a look at my example repo, none of the CSS is eliminated, but setting
|
Should be fixed by #7507 in 4.12.1 |
Not sure if this is related, but after upgrading babel to v7 (already on webpack 4.17.2), my staging/production webpack builds are missing any css including through Since I had Can someone explain me what this sideEffects is doing, why it only affects production builds, and why it was working with Babel v6 and not with babel v7 ? |
@sokra I just hit this issue in 4.27.1. It was also reproducable in https://github.com/brycehill/webpack-css-order with the upgraded webpack version. Because of this I can't set |
I'm also seeing this in 4.27.1 and 4.28.3. |
I'm seeing this in 4.29. When I remove the 'sideEffects' property from one my vendor libraries the css order between production and dev are the same but when the property is included they are not. |
@sokra Did this get deliberately reverted, or can the same fix just be reapplied to master? |
v4.30.0 - broken css order when you import your css files in js |
Attention, as before, when switching from one mode to another, for some strange reason, order gets lost! |
When import file from node_modules which has declared I have created a test repo: https://github.com/Javey/webpack-tree-shaking-demo |
This issue had no activity for at least three months. It's subject to automatic issue closing if there is no activity in the next 15 days. |
@webpack-bot please don't. This is an important issue and I'm disappointed we still haven't been able to solve without copious amounts of "!important" rules. |
@darylteo don't worry we check all PRs what bot closed |
It's pretty obvious, but might help someone. Hi guys. I'm not sure, that what i'm going to say is fully applicable to covered situation, but i had the same issue. The reason was obvious and i am a bit shy about not figuring out this in first minutes of investigation:
All i had to do is switch order for last two guys. |
The "sideEffects" property in package.json improves webpack treeshaking. However that causes the out-of-order CSS we were seeing in production builds. We may enable again once the bug is fixed. For more context see webpack/webpack#7094 and webpack-contrib/mini-css-extract-plugin#202.
The "sideEffects" property in package.json improves webpack treeshaking. However that causes the out-of-order CSS we were seeing in production builds. We may enable again once the bug is fixed. For more context see webpack/webpack#7094 and webpack-contrib/mini-css-extract-plugin#202.
Does it mean that I have to mark all JS files that import CSS directly or indirectly as having side effects? |
@alexander-akait is it still an issue for |
@vankop need tests, I think no |
Hi friends! I just made a detailed repro with Dropping |
In case you're curious, I have apparently worked around the issue with a Babel transform that traverses the dependencies and adds transitive CSS imports to every JS file in depth-first order: VKCOM/VKUI#1933 Not sure if it's a stable fix though. |
Here is an explanation why it behaves that way. Using the example here: https://github.com/thoughtspile/mini-css-extract-plugin-order-repro If the order of some modules matter they are not side-effect-free. In this example In addition to that mini-css-plugin makes no strong guarantee about the order of independent CSS files. It tries its best to keep the importing order, but there are some cases where this is not followed, e. g. because modules are split into multiple css bundles. I would recommend to not rely on CSS order between multiple files in general. If you really want to, make sure to So best don't mix class names from different origins on the same element. You can use composition/nesting instead. Nonetheless I think we can change the order in the case where it's directly imported in a certain order... |
Thanks for the response! I've spent quite some time on a task to end up facing this issue, so I'd like to discuss a bit. Use case background first. Our component library, VKUI, has ~100 components, but an average app only uses ~30. Eliminating unused CSS seemed like an easy win. We also rely on
I see that the whole idea of tree-shaking CSS is shaky, because it's trying to be both a side-effect (the module that directly imports it relies on it implicitly) and non-side-effect (because you can remove it when you don't have a direct import in used modules). Could you please explain how I'd like to avoid nesting (if you mean having
Shipping with I am arriving at the conclusion that a UI kit without CSS-in-js or an advanced CSS variable system is not possible, but just wanted to try one last time. |
|
Note, that completely broke my build. Console error:
I was trying this as a workaround suggested here: vuetifyjs/vuetify#13732 |
Fwiw, I had been using |
I got around this issue by adding Edit: Without modifying sideEffects, it actually seems to be producing class names in the exact opposite order that I would expect. |
I created an issue in CSS files are concatenated in the order they're imported. Webpack seems to reorder imports of side effect free modules. We're supposed to counteract it with the However, it seems like
|
@alexander-akait Greetings! Is there currently any way to solve the problem with the order of styles when using tree shaking? My case:
When you enable tree shaking in webpack (specify sideEffects: ["/.css", "/.scss"]), problems with css formation begin, namely, the order of modules entering the final css file ceases to be predictable and logical.
With tree shaking turned off, we will have the following final css file:
That is, everything will work as expected, first come the styles of the Title component, then the styles of the Content component. The passed class from Content to Title will be below, so styles can be easily redefined. However, when tree shaking is active, the style order will be the opposite of what we expect, i.e.:
In this case, the styles from the Content will not be able to override the styles of the Title, respectively. |
Yeah, it is a bug inside webpack, I don't look deeply at this right now, so no solution right now, you can try to solve it on the CSS side, i.e. use css specificity, I know it is not a perfect solution, also you can try to use CSS modules |
@alexander-akait I'd like to fix it myself if possible, would you accept a PR? I haven't done any contributions to webpack yet though, what do you think is the scope of this issue? Any suggestions as to where I should start investigating? webpack/lib/buildChunkGraph.js Line 792 in 6ccd531
|
@kosciolek I'm afraid this is not an easy task, you can start with adding failed test cases and then we will look how to fix it |
One of the commits in 5.90.2 seems to have fixed it, at least for the reproduction I made above. However, our larger project still has this problem, but it's likely it's something on our side. |
@kosciolek Yeah, we can also have some edge cases, so, if you can provide an example I will investigate it
Release will be today/tomorrow, need to finish one small thing |
This is the commit in 5.90.2 that fixed the issue in the reproduction:
Adding these 3 removed lines back breaks the repro again: a2ce375#diff-926fcfc6c89e458cc222fa6b30ac4150fca4140e70522c08fa661b005da45b48L102 |
@alexander-akait I made a PR with a failed test case As stated above, after 5.90.2, the reproduction I linked above is no longer applicable (apparently it's fixed), but now there's another problem when optimizing reexports of modules that import side-effectful modules. Commenting this line out webpack/lib/optimize/SideEffectsFlagPlugin.js Line 341 in 6ab9bda
|
Do you want to request a feature or report a bug?
Bug
What is the current behavior?
CSS seems to be out of order in "development" vs "production" mode. It appears somehow related to
sideEffects
and tree shaking.If the current behavior is a bug, please provide the steps to reproduce.
Here's a repo demonstrating the issue: https://github.com/brycehill/webpack-css-order.
There are instructions in the readme. Basically, if you build in
development
mode, the outputted CSS is different fromproduction
mode.What is the expected behavior?
CSS order is consistent from one environment to another.
I don't want to depend on a specific CSS order, but I do expect it to be consistent from when I develop to when I build for production.
If this is a feature request, what is motivation or use case for changing the behavior?
N/A
Please mention other relevant information such as the browser version, Node.js version, webpack version, and Operating System.
Node: v8.9.1
Webpack: v4.6.0
OS: MacOS High Sierra
The text was updated successfully, but these errors were encountered: