composes order

[sullenor]

Just wanted to add the issue as a reminder of the unpleasant use case.

In case there is a selector with a multiple composes rules and another preceding one, which contains the same composes rules, but in the another order, it may result in the confusing order of the resulting css.

For example:

.localA {
  composes: D from './d.css';
}

.localB
{
  composes: F from './f.css';
  composes: D from './d.css'; /* should come after f.css */
}

transforms into

:import("./d.css") {
  i__imported_D_0: D
}

:import("./f.css") {
  i__imported_F_1: F
}

...

:export {
  localA: _source_localA i__imported_D_0;
  localB: _source_localB i__imported_F_1 i__imported_D_0
}

which means, that the contents of the d.css will be loader before f.css.
That may lead to a small collapse for the .localB selector in case F and D contain similar rules.

Relates to css-modules/css-modules#12

[delijah]

Any progress on this?! This is quite annoying!

[sullenor]

It's published as prerelease and available under dist tag.
To install it manually you should use npm i postcss-modules-extract-imports@next.

[sullenor]

https://github.com/css-modules/postcss-modules-extract-imports/releases/tag/v1.2.0

[sgal]

Is there any plan to get this published? Do you need any help with testing etc.? This issue was biting us for quite some time already, so it'd be great to have it published.

[sullenor]

It is published for now (2.0.0).