Breaking change of styles' loading order @ 0.6.0

[keann]

Hi guys.

Let's say there is a following case:

├─ blocks
│ └─ Example
│ │ ├─ _mod1
│ │ │ └─ Example_mod1.css  /* styles #1 */
│ │ ├─ _mod2
│ │ │ └─ Example_mod2.css  /* styles #2 */
│ │ ├─ Example.css         /* styles #0 */
│ │ └─ Example.js
└─ app.js

/*   Example.js   */
...
import 'm:mod1';
export default decl({
  block: 'Example'
});

/*   app.js   */
...
import Example from 'b:Example m:mod2';
...

where mod1 is pretty lightweight and widely used (e.g. some disabled state with one-two loc), thus it's just easier to include it as a base block functionality (but still keep in a separate folder for clarity). Obviously, as mod1 overrides block's base styles, its css should be loaded after the main one.

With loader version <=0.5.1 loading order of styles was predictable & ok: 0 -> 2 -> 1.
But with 0.6.0 now it is 1 -> 0 -> 2 and totally breaks existing logic, described above.

[Yeti-or]

Valid issue, we will fix it

[Yeti-or]

@keann check v0.6.1, please

[keann]

@Yeti-or @bem/[email protected] broke everything everywhere)

For example, this code

/* project/blocks/Header/Header.js */
import pt from 'prop-types';
import { decl } from 'bem-react-core';

import 'm:font=roboto|ubuntu';
import 'm:row';
import 'm:size=16|20|24|28|32|40|56';

export default decl(
  {
    block: 'Header',
    ...
  }
);

was previously turned into

and now it's

where requiring of Header.js from itself results in an object:
(kind of webpack's way of handling recursive require?)

(caught on a breakpoint, and "102" is a webpack's module id of a _Header.js_ script)

So on the 25th line above there is an error of "applyDecls is not a function", because it's, well, undefined.

PS. Webpack version: 3.11.0

[keann]

Thanks a lot for the latest fixes, with 0.6.2 require-chains look much better! For the one who might read this thread in future: as a result the loading order became 0 -> 1 -> 2, what deprives undocumented, yet convenient possibility to make rules in 1 the most important (w/o !important or specificity tricks). But, according to indices, it's the most obvious order, and I totally accept it.

I'm afraid, there is another problem now 😅 Here context of a block seems to be its folder. If we have inside this folder some related test- or preview-files, that condition also prevents from pushing a require of a block itself inside them. As a result it's impossible to import a block anywhere in its folder.

Update
Not sure, which particular update it's about, but the problem above is solved as well by now.