css-loader: ICSS: Importing a composed class name produces wrong output

Operating System: Linux
Node Version: v10.17.0
NPM Version: n/a, Yarn 1.15.2
webpack Version: 4.41.2
css-loader Version: 3.2.0

Expected Behavior

css-loader should produce correct output:

.outer-box__outerBox--1rUd7j4- .inner-box__innerBox--19HrVC2M.shared__box--3DFGfIs1 {
	background-color: lime;
}

Selection_407

Actual Behavior

css-loader produces incorrect output:

.outer-box__outerBox--1rUd7j4- .inner-box__innerBox--19HrVC2M shared__box--3DFGfIs1 {
	background-color: lime;
}

Selection_406

Code

See below.

How Do We Reproduce?

Full repro case here: https://git.cryto.net/joepie91/icss-loader-test

Run yarn webpack to produce output with Webpack + css-loader (incorrect output), run yarn browserify-extract to produce output with Browserify + icssify (correct output).

Both output to the same files, so you can switch between them. Open test/index.html in a browser to see the result.

The bug is caused by the import handling using the JS/HTML-formatted (space-delimited) export, rather than a CSS-formatted (dot-delimited) export.

This means that when using a composed identifier (which consists of two space-delimited class names) as an imported identifier, the resulting selector rule will be broken (see code snippets above).

This can be fixed by replacing spaces with dots in the case of ICSS imports.

About this issue

Original URL
State: open
Created 5 years ago
Reactions: 4
Comments: 20 (11 by maintainers)

Most upvoted comments

Any workaround for this issue?

abhijithqb on Mar 18, 2021

@apexskier That’s a different issue, about imports not working at all. That has since been fixed, as far as I can tell.

The remaining issue is that specifically composed class names are not handled correctly, for which I’ve provided a reproduction in the initial report above.

joepie91 on Feb 17, 2020

@OHUSAR Thanks, I will look at that in near future

alexander-akait on Jul 23, 2020

Hello.

We are also experiencing similar issue to this. In our case its an issue with using composes with dynamically imported css chunks.

I have created a minimal reproduction:

https://github.com/OHUSAR/css-modules-chunk-specificity-bug

@evilebottnawi is this an issue, you will be considering to look into, or should we use different way of solving our problems? Thank you for your answer!

The precise definition of the problem (pasted from README.md):

Let’s consider having these source files:

a.module.css
```
.test {
    background-color: red;
}
```

b.module.css

.test2 {
    composes: test from "./a.module.css";
    background-color: blue;
}

c.module.css

.test3 {
    composes: test from "./a.module.css";
    background-color: green;
}

The output of these files would be:

a.module.css
```
.test {
    background-color: red;
}
```

b.module.css

.test {
    background-color: red;
}

.test2 {
    background-color: blue;
}

c.module.css

.test {
    background-color: red;
}

.test3 {
    background-color: green;
}

Now let's consider that our code dynamically imports chunk with output of a.module.css and c.module.css and than later imports chunk with b.module.css output.

The current applied css would be:

    .test {
        background-color: red;
    }

    .test {
        background-color: red;
    }

    .test3 {
        background-color: green;
    }

    .test {
        background-color: red;
    }

    .test2 {
        background-color: blue;
    }

When considering element using classnames from c.module.css,

    <div class="test_localname test3_localname" />

the applied background color of the C element would be red instad of green. The reason for this is that the class .test is included later in the css hierarchy and therefore is used for element style.

OHUSAR on Jul 23, 2020