Resolve css-loader v4 + babel-plugin-react-css-modules incompatibility

[Mr0grog]

See also #580.

I messed up when checking dependency updates today, and upgrading from css-loader v3.6.0 to v4.2.0 totally hosed the layout. The core problem is that in v4, css-loader and babel-plugin-react-css-modules generate different hashes for identifiers. Specifically:

1. They depend on different versions of loader-utils, and the default hash type changed from md5 to md4. We can work around this by explicitly specifying the hash type on our identifier template:

   Current:    "[path]___[name]__[local]___[hash:base64:5]"
   Workaround: "[path]___[name]__[local]___[md5:hash:base64:5]"
   

2. They compose the core value of the hash in fundamentally different ways. The changes in question happened here: webpack-contrib/css-loader@d2f6bd2

   Working around this would require either:

   • Not using a hash in the identifier name (at least, although that still puts us on tenuous ground for other kinds of future changes).
   • Specifying a function for both babel-plugin-react-css-modules and css-loader instead of strings. This should be possible, but there’s an open issue about it not working right on babel-plugin-react-css-modules. Not sure whether that’s accurate or not.

[Mr0grog]

Thinking about this more, the ideal fix may be to just remove the hash from our identifiers. All the info involved in the hash is also in our current identifiers, so the hashes aren’t generally adding any useful differentiation for us, and are probably safe to remove.

The hash in css-loader is hashPrefix (which we leave blank) + request (the path to the CSS module file) + localName (the CSS rule identifier as the author wrote it, like .alert): https://github.com/webpack-contrib/css-loader/blob/d24f9c72589b5da1f30ab549b9c474aecbe8921f/src/utils.js#L57-L65

The hash in babel-plugin-react-css-modules is hashPrefix + filepath + localName: https://github.com/css-modules/generic-names/blob/d57cb1c4dbf391fb68be9e5f38e68ad1d5a0f2d9/index.js#L33-L42 (This comes from the “generic-names” package, which is used by babel-plugin-react-css-modules.)

So as long as our identifiers include all of [path], [name], and [local], the hash is redundant.

[Mr0grog]

Obviously the other big option here is to just use the module functionality in css-loader without adding react-css-modules or babel-plugin-react-css-modules at all. We lose one really nice feature and a few minor conveniences:

• No build-time warning if you reference an non-existent CSS rule (or have a type in your name). This is a pretty useful feature we lose.

• When referencing CSS rules in our JSX, we have to use camel-cased versions of the name. e.g. if the CSS has .alert-info, the JSX will have style.alertInfo. (Similarly, you also need the style.* part.) This could be confusing, but I don’t think it’s any less to learn than the fact that our names currently have to be in the styleName prop instead of className. ¯\_(ツ)_/¯

• Using multiple classes or mixing module and global classes is less nice. The way we have it now, with babel-plugin-react-css-modules:

  // One plain old module-based rule (the common case):
  <div styleName="my-module-based-css-rule"></div>
  // Combining multiple rules from a module:
  <div styleName="my-module-based-css-rule another-module-based-css-rule"></div>
  // Combining module and global rules:
  <div styleName="my-module-based-css-rule" className="my-global-rule"></div>

  And with just css-loader:

  // One plain old module-based rule (the common case):
  <div className={style.myModuleBasedCssRule}></div>
  // Combining multiple rules from a module:
  <div className={`${style.myModuleBasedCssRule} ${style.anotherModuleBasedCssRule}`}></div>
  // Combining module and global rules:
  <div className={`${style.myModuleBasedCssRule} my-global-rule`}></div>

…But we then have fewer moving parts that have to be carefully coordinated.

[Semigradsky]

@dr.pogodin/babel-plugin-react-css-modules fork works like a charm.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in seven days if no further activity occurs. If it should not be closed, please comment! Thank you for your contributions.