style is not affective on vue demo

[eminoda]

• Operating System: window10
• Node Version: v10.15.3
• NPM Version: 6.4.1
• webpack Version: 4.44.1
• css-loader Version: 4.2.0

Expected Behavior

I use wepback make a simple vue demo, try to use scss-loader parse scss style, expect below picture

Actual Behavior

but，now is this picture. You can css style is not become effective, because <style> attribute is not appear to html.

Code

{
        test: /\.scss$/,
        use: [
          {
            loader: 'vue-style-loader',
            options: {
              // sourceMap: false,
              // shadowMode: false,
            },
          },
          {
            loader: 'css-loader',
            options: {
              // sourceMap: false,
              // importLoaders: 2,
              // modules: {
              //   localIdentName: '[name]_[local]_[hash:base64:5]',
              // },
            },
          },
          {
            loader: 'sass-loader',
            options: {
              sourceMap: false,
            },
          },
        ],
      }

// additional code, HEY YO remove this block if you don't need it

Solution

I try to downgrade css-loader to 3.5.3，webpack builded ok，I dont know why is it.

[birdofpreyru]

I believe, I know why it happens: in their update from v3.6.0 to v4.0.0 they bumped loader-utils dependency from v1.2.3 to v2.0.0. That altered generated hashes in class names, and right away breaks any web app setups with server-side rendering, as hashes generated at server-side (usually with alternative tools) mismatch hashes generated by webpack-bundled JS. Very bad, css-loader guys did not noticed this change, and have not mentioned it explicitly as a huge breaking change in the release notes.

Also, I am still struggling to figure out how to achieve old hash values with the latest css-loader. I figured out, the loader-utils changed the default hashing algo from md5 to md4, but so far it seems that just specifying md5 explicitly still does not result in the old values. Should be some extra changes affecting hashes (or might be I am doing something stupid).

UPDATED: And I found the second reason of changed hashes:
https://github.com/webpack-contrib/css-loader/blob/master/src/utils.js#L60
It used to join the path and class name by + in v3.6.0, now it joins them by \u0000. As it is hard-coded, there is no way to keep hash values with v3.6.0 > v4.2.0 upgrade 😭

[alexander-akait]

It is expected, because we have some rare cases where generated classes can be potential same for difference classes, so we fix it, you can use getlocalIdent() if you want to return previous behavior

[alexander-akait]

Also, I am still struggling to figure out how to achieve old hash values with the latest css-loader. I figured out, the loader-utils changed the default hashing algo from md5 to md4, but so far it seems that just specifying md5 explicitly still does not result in the old values. Should be some extra changes affecting hashes (or might be I am doing something stupid).

You should not use old algorithm, because it has collisions as I described above

Just regenerate classnames

[alexander-akait]

changed the default hashing algo from md5 to md4

Because md4 is faster for hashing, it is the perf improvement

[alexander-akait]

Why you need old classes? We have exportOnlyLocals for SSR, you should never use hardcoded classnames

[birdofpreyru]

@evilebottnawi well, I wouldn't care much about the algo you prefer, but...

There is https://www.npmjs.com/package/babel-plugin-react-css-modules (125k weekly downloads)
and there is https://www.npmjs.com/package/babel-plugin-css-modules-transform (51k weekly downloads),
both relying on matching classnames with css-loader.

I guess, I'm now to fork & update them sometime soon :)

And I am not sure what Vue is using, but I guess in the nutshell it bumps into a similar problem ¯_(ツ)_/¯

[alexander-akait]

babel-plugin-react-css-modules need to update and has incompatibility with current implementation 😞 Why do you use this? There are a lot of alternative solutions

[birdofpreyru]

I use it in my React setup since 2018. It looked like a great choice back then, and it did not caused me any issue since. If something is not broken I don't fix it :)

I'll appreciate if you suggest a better alternative, or warn me about any incompatibility issues beside the classname difference discussed above. With what I know currently, the option to just fork / update / package my own version of babel-plugin-react-css-modules seems like the easiest and fastest to me :)

[alexander-akait]

You can use exportOnlyLocals to implement SSR, is it what you search?

[birdofpreyru]

I guess, it would work if I pass server-side code through Webpack, but that's not how I do stuff. I only use Webpack to bundle the client-side code, and the server-side code I just compile with Babel only.

[alexander-akait]

hm, make sense, in your case I recommend to migrate on the getLocalIdent option, it is allow to control it, also will be great to implement it on babel-plugin-react-css-modules side

[ThiefMaster]

Could you provide an example on what to specify as getLocalIdent to restore compatibility with babel-plugin-react-css-modules?

After looking at the implementation this looks like a huge pain in the ass to fix. getLocalIdent calls multiple functions coming from other libraries, so it looks like I'd have to add those as dependencies to my application just to keep using the old implementation...