Consider swapping css-modules tooling for modular-css

[jquense]

💬 RFC

Proposal, swap out css-modules toolchain for modular-css.

🔦 Context

Parcel currently has support for css-modules (yay!), but it's through very unmaintained postcss plugins from the css-modules org. These tools are pretty out of date at this point, and most of the interesting modern support for css-modules basically only exists in webpacks css-loader. Stuff, like interpolating values in selectors, (which we depend on to make component interpolation work in astroturf)

Overall the original the css-modules tooling is mostly abandoned. I've made a few attempts to try and revive/takeover/maintain these repo's but everyone if fairly unresponsive, so it seems likely they will stay that way. Since no one maintains, the pure postcss tools anymore parcel support will get more and more out of date, even if there is some life in the specific plugins that css-loader uses.

All that to say, that @tivac maintains modular-css which is functionally the same as css-modules, but with sharp edges filed down, and active development. It's not a drop in replacement, but it is very close, actively maintained, and functionally better (both to use and consume), It'd be awesome to adapt it as the basis for css module support in Parcel.

it would improve the support for folks using css-modules as well as tooling like astroturf which is currently hobbled in parcel b/c of missing features.

Thanks!

[DeMoorJasper]

Interesting, I've never heard of this library before but seems interesting.

Would be cool to switch if it's just as stable and supports all the same features + more

[devongovett]

Are there breaking changes between css-modules and modular-css? What are the differences between modular-css and whatever webpack has?

[jquense]

This https://m-css.com/guide/#vs-css-modules is a good resource. There are breaking changes, mostly around removing ambiguous or confusing css-module features. Rules around :global usage are simpler for instance. There is a lot of cruft in the css-module tooling from early when we didn't have patterns and usage yet. For instance css-modules, assumes everything is global, unless you include the plugin to walk every id and class and wrap it in :local(), which is then scoped. In practice no one ever wants "global as default" so there is always a lot of work done that doesn't need to be on the style AST. Modular-css removes that default, a breaking change but arguably if css-modules was actively developed they'd have made the same change long ago.

There are also a few features that webpack/css-modules doesn't have. The big one for me is :external for referencing classes from other modules, I've hacked a similar feature into css-modules in css-loader v3 but it's tries to shoehorn it into the way @value works and the tooling and design clearly doesn't work well for that, so it's a bit broken.

Another win is that modular-css has better errors, due to more cohesive tooling. Since it's not implemented as a bunch of a la carte postcss-plugins, tools have more context as to what is wrong and when things are being referenced that don't exist, etc.

It's also worth mentioning that we are actively testing a similar switch for webpack, see the discussion here with the css-loader maintainer: css-modules/css-modules#324 (comment)

[jquense]

Some additional context here: https://github.com/jquense/css-module-loader#migrating-from-css-loader

I've written a set of postcss-plugins that paper over compatibility issues with switch to modular-css. I'd be happy to release them independently as well as an easy migration path for existing users

[devongovett]

We have now swapped to our own @parcel/css for this by default.

[jquense]

🎉