Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: Refactoring + Simplicity + Co maintainer ^^ #53

Closed
mhsdesign opened this issue Mar 25, 2023 · 3 comments
Closed

Question: Refactoring + Simplicity + Co maintainer ^^ #53

mhsdesign opened this issue Mar 25, 2023 · 3 comments

Comments

@mhsdesign
Copy link

mhsdesign commented Mar 25, 2023

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants