Question: Refactoring + Simplicity + Co maintainer ^^

[mhsdesign]

Hi ;) i lately had also the need for an esbuild css modules plugin for a project which also uses css modules composes: className from "./file.module.css" I tried all existing css modules plugins but they wouldnt work for this case - as post-css-modules has a (sorry) horrible api.

After countless hours i found parcels lightningcss which worked like a charm and has a super nice api. So i created a fully functioning, simple and readable css modules plugin with only ~100 lines of code.

You can see my implementation here: https://github.com/neos/neos-ui/blob/a0683ed157699042aa269ea0819977efafb5be46/cssModules.js (inlined in the bespoken project)

The reason why im reaching out to you is, that yours is the only esbuild css modules plugin of around 10 others which uses lightningcss as implementation. So i though creating my own css modules plugin (with the above implementation), to have 11 competing plugins, would not be what open source is about - instead i want to ask you if we want to improve your codebase together?

Mainly im thinking about:

• make the code easier to maintain / reduce complexity
  • remove the v1 version or extract it into an own package
  • that way we have less dependencies
  • less code to maintain here
  • no confusion with version switches (i dislike feature flags a bit ^^)
  • find out why your code is 4x that long (complex), and what can be optimized/refactored
• implement css composes
• do we really need caching? The mentioned big project with around 100 css module files seems to build super smooth without any cache.

I would really like to chat (or maybe have call) with you about the above points and implement them together.

What do you say?

[indooorsman]

Glad to see your points, thanks.

remove the v1 version or extract it into an own package

I'm planning to deprecate v1 as well.

find out why your code is 4x that long (complex), and what can be optimized/refactored

Maybe it's caused by the inject feature, not sure for now, I need more time to investigate.

implement css composes

I see https://lightningcss.dev/css-modules.html has already supported compose, I think it will be easy to support it in our plugin.

do we really need caching?

No I think 🤣

In total, I agree with you, but to be honest, I'm really busy on my full-time job recently, thus no detailed plan for these changes for now 😢

[mhsdesign]

Hi thanks for your response ;)

Maybe it's caused by the inject feature, not sure for now, I need more time to investigate.

Ah yes i see that seems to introduce some complexity ;) But as you said that you dont have much time currently and since i have to little knowledge of your project to refactor it myself*, i think i will just go ahead and create yet another css module plugin xD

*Plus i must say that im not looking into maintaining the complex inject feature, and removing it would require a complex migration for the user

Will let you know when i published my minimal lightning css modules plugin, and maybe you can reference it in your readme? ^^ So my plugin could profit from a bigger user base and become more stable for edge cases ;)

[mhsdesign]

voila ;) https://github.com/mhsdesign/esbuild-plugin-lightningcss-modules