CSS load order when using `composes`

[jason0x43]

Bug

This may be outside the scope of this package, but just in case...

When I have a .m.css file that composes a class from another css file, I expect the file being extended to be loaded first in the resulting bundle, so that the rules in the file doing the extending have precedence. In other words, if I have:

// a.m.css
.root {
    border-color: blue;
}

// b.m.css
.root {
    composes: root from './a.m.css';
    border-color: red;
}

I would expect the border-color from the class doing the extending (.root in b) to override the rule from the base class (.root in a). This requires that the 'a' stylesheet be loaded into the DOM before the 'b' stylesheet. Unfortunately, that doesn't always seem to be happening.

Package Version: 0.3.0

Code

See https://github.com/tomdye/dojoThemeComposition

1. Run dojo build -w
2. Add a background rule to the .root class in base/helloWorld.m.css
3. Note that both the 'base' styled block and the 'dark' styled block now have the background color from 'base' even though 'dark' is intuitively overriding it.

Expected behavior:

The background specified in the .root of the 'dark' theme should override the background from the 'base' .root.

Actual behavior:

The background in the 'base' .root is applied to both the dark and base themed blocks. From looking at Chrome's dev tools, the 'base' rules have been loaded after the 'dark' rules.

[kitsonk]

If load order effects the run-time behaviour, then cli-build-webpack/cli-build-app needs to be concerned with this, IMO.

[tomdye]

@jason0x43 this is external to our build pipeline and is an issue / implementation detail of post-css css-modules plugin. It is related to how two classes get mapped to the single original class when using composes.

There is a work-around for all classnames apart from the top level root as we discussed last night using a local class. This is documented in the css-modules readme

There can be multiple composes rules, but composes rules must be before other rules. Extending works only for local-scoped selectors and only if the selector is a single class name. When a class name composes another class name, the CSS Module exports both class names for the local class. This can add up to multiple class names.

[tomdye]

I will set up a test environment to see if this can be solved by using imports at the top of the css file to ensure the order that files are included. If this does not work then I believe it to be out of our hands as it is a known limitation / external issue with css-modules as mentioned in my previous comment

[agubler]

@tomdye did you manage to set up a test environment to prove this?

[agubler]

@tomdye did you ever get round to testing this? If so what was the conclusion and does it effect the new build commands? If not can you test it on the new build commands and close or move the issue as required?