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.

using sideEffects you say order doesn't matter

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 sideEffects: true fixes the problem. To reiterate from my previous comment:

For me, the final order doesn't matter, but what does matter is a consistent order between development and production environments

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 import "./style.less" calls.
After some tedious debugging, I found out that adding the cli option -p or the config mode: "production", (or both) will break the build (which means that dev build works without any problem).

Since I had "sideEffects": false, in my packages.json, I changed it to "sideEffects": ["*.css", "*.less"],, and it seems to have fixed my build.

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 "sideEffects": false nor "sideEffects": ["*.css"] in my package.json, otherwise it affects the CSS-order which causes styling issues.

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.

Looks like this was fixed in v4.12.1 as described by @sokra, however it broke again in the next minor release (v4.13.0).

I pushed an update to my test repo showing this.

@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
v4.31.0 - seems css order is as expected!

Attention, as before, when switching from one mode to another, for some strange reason, order gets lost!
To fix this you need to do npm cache clear --force
Why?

When import file from node_modules which has declared "sideEffects": [".*css"] in package.json, the css order is unexpected, but it's ok when import file from root directory.

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.
TL;DR:
For multiple entries configuration. This might be caused by scripts order in your index.html.

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.
In my React project i had 3 bundled .js files (vendors.bundle.js, first.bundle.js, second.bundle.js). We've been using style modules (imported styles).
When i was working in devenv, everything was cool. But after building for production styles become messy. Some was overwritten by another ones and so on.

The reason was obvious and i am a bit shy about not figuring out this in first minutes of investigation:
Scripts load order. Which was:

...
<script src="./vendors.bundle.js" type="text/javascript"></script>
<script src="./second.bundle.js" type="text/javascript"></script>
<script src="./first.bundle.js" type="text/javascript"></script>
...

All i had to do is switch order for last two guys.
Hope it might help someone like me. Cheers.

using sideEffects you say order doesn't matter

Does it mean that I have to mark all JS files that import CSS directly or indirectly as having side effects?

Well, if you need something fast and dirty you may apply webpack+4.46.0.patch.txt via patch-package... The patch most probably breaks something somewhere since it makes HarmonyImportSideEffectDependency to behave exactly as HarmonyImportDependency and removes dependencyReference hook call in Compilation.js. But it makes development and production CSS order to be consistent for me.

Note, that completely broke my build. Console error:

TypeError: (void 0) is not a function

I was trying this as a workaround suggested here: vuetifyjs/vuetify#13732

Fwiw, I had been using treeShake: false in my nuxtjs-vuetify module settings due to a separate issue I was experiencing before. Removing that fixed the CSS order issue. To fix the other issue, I had to import a component I was rendering conditionally with import { VCard } from 'vuetify/lib'.

I got around this issue by adding sideEffects: true to all of my webpack loader configs. Not the most ideal as it disables tree-shaking appwide. Hoping someone may have found a better solution.

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 mini-css-extract-plugin's repo. It might or might not be related: webpack-contrib/mini-css-extract-plugin#1070

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 sideEffects field in package.json.

However, it seems like "sideEffects": ["*.css"] does not work properly for external packages (i.e. from NPM, or other packages from your monorepo).

1. It works for your local files. If declared inside the package.json of your app, then CSS files under your src will not be tree shaken out, and they also will be included in the correct order.
2. BUT, if you import a package which has "sideEffects": ["*.css"] in its package.json, then its CSS will not be tree shaken out, but it might be loaded in the wrong order, as webpack reorders imports by the time mini-css-extract-plugin runs!

Here is a simple reproduction with a description.

@alexander-akait Greetings! Is there currently any way to solve the problem with the order of styles when using tree shaking?
I saw that the task has been moved to high priority in webpack 5/6, but if this can somehow be solved now, that would be just great.

My case:
On the react project.js using webpack 5.
Styling via css modules from under scss.
That is, each component has its own css module, for example:

component
  Component.js
  Component.module.scss

// Component.js
import React from 'react'

import styles from './Component.module.scss'

const Component = () => {}

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.
For example, there are two react components.js, Title and Content. In the Content component, we want to reuse the Title component, and pass other styles to it via className prop:

components
  title
    Title.js
    Title.module.scss
  content
    Content.js
    Content.module.scss

// Title.js
import React from 'react'
import cx from 'classnames'

import styles from './Title.module.scss'

const Title = ({ className }) => (
  <h1 className={cx(styles.title, className)}>Title</h1>
)

// Title.module.scss
.title {
  background: red;
}

// Content.js
import React from 'react'

import Title from '../title/Title'

import styles from './Content.module.scss'

const Content = ({ className }) => (
  <Title className={styles.title}></Title>
)

// Content.module.scss
.title {
  background: blue;
}

With tree shaking turned off, we will have the following final css file:

.components_title_title {background: red;} 
.components_content_title {background: blue;} 

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.:

.components_content_title {background: blue;}
.components_title_title {background: red;} 

In this case, the styles from the Content will not be able to override the styles of the Title, respectively.
This is very demotivating, because I want to take advantage of tree shaking, but because of this problem with styles, I can’t do it.

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?

@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

One of the commits in 5.90.2 seems to have fixed 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:

a2ce375

commit a2ce375d968a9ef5e8b9ee59a30268d3b35c864a
Merge: 2a063f88d 1673ee5d1
Author: Alexander Akait <4567934+alexander-akait@users.noreply.github.com>
Date:   Mon Feb 12 13:37:05 2024 +0300

    fix: use new runtime to reconsider skipped connections activeState

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

Any update on this? I have this problem as well. The uikit I'm using has {"sideEffects": [".css", ".scss"],} in its package.json.

Code:

import { Button } from "@gravity-ui/uikit";
import "./main.css";

ReactDOM.createRoot(document.getElementById("root")).render(
    <Button>sdf</Button>
);

Css build result:

// Css from main.css
.main {
  ...
}

// Button css
.button {
  ...
}

One solution to avoid this problem as a component library author is to add all styles in a component library package to a CSS layer. In this way, the styles in the consuming application always take precedence over the styles in the library package no matter what the order of appearance is.

But keep in mind that style rules with less specificity will have precedence as well. So if you have some sort of CSS reset in addition to the library package, you might want to add this to a CSS layer as well and define the order early in the application.

I just stumbled a similar behaviour.

Setting sideEffects: false together with barrel files creates the following dependency graph:

graph TD
    subgraph "No Barrel ✅"
        A3["@applications/base/src/index.ts preOrder: 0, postOrder: 6"]
        B3["@libraries/teaser/src/teaser.ts preOrder: 1, postOrder: 5"]
        E3["@segments/carousel/src/buttons.ts preOrder: 2, postOrder: 2"]
        F3["@segments/carousel/src/button.module.css preOrder: 3, postOrder: 1"]
        G3["button.module.css|0|||}} preOrder: 4, postOrder: 0"]
        H3["@libraries/teaser/src/teaser.module.css preOrder: 5, postOrder: 4"]
        I3["teaser.module.css|0|||}} preOrder: 6, postOrder: 3"]
        
        A3 --> B3
        B3 --> E3
        E3 --> F3
        F3 --> G3
        B3 --> H3
        H3 --> I3
        style A3 fill:#0a0a4a,stroke:#333
        style F3 fill:#294b51,stroke:#333
        style G3 fill:#294b51,stroke:#333
        style H3 fill:#294b51,stroke:#333
        style I3 fill:#294b51,stroke:#333
    end


    subgraph "sideEffects: true ✅"
        A2["@applications/base/src/index.ts preOrder: 0, postOrder: 8"]
        B2["@libraries/teaser/src/index.ts preOrder: 1, postOrder: 7"]
        C2["@libraries/teaser/src/teaser.ts preOrder: 2, postOrder: 6"]
        D2["@segments/carousel/src/index.ts preOrder: 3, postOrder: 3"]
        E2["@segments/carousel/src/buttons.ts preOrder: 4, postOrder: 2"]
        F2["@segments/carousel/src/button.module.css preOrder: 5, postOrder: 1"]
        G2["button.module.css|0|||}} preOrder: 6, postOrder: 0"]
        H2["@libraries/teaser/src/teaser.module.css preOrder: 7, postOrder: 5"]
        I2["teaser.module.css|0|||}} preOrder: 8, postOrder: 4"]
        
        A2 --> B2
        B2 --> C2
        C2 --> D2
        D2 --> E2
        E2 --> F2
        F2 --> G2
        C2 --> H2
        H2 --> I2

        style A2 fill:#0a0a4a,stroke:#333
        style F2 fill:#294b51,stroke:#333
        style G2 fill:#294b51,stroke:#333
        style H2 fill:#294b51,stroke:#333
        style I2 fill:#294b51,stroke:#333
    end

    subgraph "sideEffects: false ❌"
        A1["@applications/base/src/index.ts preOrder: 0, postOrder: 6"]
        B1["@libraries/teaser/src/teaser.ts preOrder: 1, postOrder: 5"]
        C1["@libraries/teaser/src/teaser.module.css preOrder: 2, postOrder: 1"]
        D1["teaser.module.css|0|||}} preOrder: 3, postOrder: 0"]
        E1["@segments/carousel/src/buttons.ts preOrder: 4, postOrder: 4"]
        F1["@segments/carousel/src/button.module.css preOrder: 5, postOrder: 3"]
        G1["button.module.css|0|||}} preOrder: 6, postOrder: 2"]
        
        A1 --> B1
        B1 --> C1
        C1 --> D1
        B1 --> E1
        E1 --> F1
        F1 --> G1

        style A1 fill:#0a0a4a,stroke:#333
        style C1 fill:#294b51,stroke:#333
        style D1 fill:#294b51,stroke:#333
        style F1 fill:#294b51,stroke:#333
        style G1 fill:#294b51,stroke:#333
    end

it causes the css to be in the wrong order but I am not 100% sure if it's exactly the same issue

therefore I opened a new issue: #18961

Close in favor - #18961