WIP: Remove babel-plugin-react-css-modules a.k.a. styleName vs className

[neonnoon]

Issues are not enabled on this repo, therefore I submit this proposal as a (partial) PR.
The goal here is to get rid of babel-plugin-react-css-modules, because:

• it is not compatible with css-loader v4 (needed for webpack v5), see Not compatible with css-loader v4 gajus/babel-plugin-react-css-modules#291
• it seems the repo is abandoned and an "inofficial" fork availabel here: https://github.com/birdofpreyru/babel-plugin-react-css-modules

In order to stay future proof and reduce dependencies on abandoned projects I suggest that we move from styleName to className. In addition to that IDE support is able to detect proper class names (as they're variable names as opposed to string literals).

Please lemme know what you think of this proposal and I'll have a look at it.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[sosostris]

Happy snowman-burning Day @neonnoon ! ⛄

We were discussing today about the upcoming clsx PR. Our idea is,

1. For pyrene, we do everything in one big PR, including

• introducing clsx to pyrene
• convert all pyrene components to use clsx

2. Then we need two separate PRs to handle:

• tuktuktwo
• pyrene-graphs

@Sakai-san please correct me if I'm wrong :)

I have two questions:

1. For the pyrene part, would you prefer that we work on top of this PR (e.g. making new commits to this PR), or it's better that we start a separate PR?
2. pyrene, pyrene-graphs and tuktuktwo will all have their dependency on clsx, could peer dependency be somehow employed to alleviate the issue that at some point there will be 3 different versions of clsx?

[Sakai-san]

@Sakai-san please correct me if I'm wrong :)

I have two questions:

1. For the pyrene part, would you prefer that we work on top of this PR (e.g. making new commits to this PR), or it's better that we start a separate PR?
2. pyrene, pyrene-graphs and tuktuktwo will all have their dependency on clsx, could peer dependency be somehow employed to alleviate the issue that at some point there will be 3 different versions of clsx?

@sosostris, @sanmiawi

1. I would create a brand new PR branched off that present PR for all the remaining components.
2. I would not treat it as peerDependency since the main project does not have any package.json.

[neonnoon]

• I would create a brand new PR branched off that present PR for all the remaining components.

Whatever works best for you. Generally, I think we have a bit of a mess with PRs. If you wanna branch off this branch for further changes, I think we can just kill this PR (the branch will remain and can be used as a base).

• I would not treat it as peerDependency since the main project does not have any package.json.

What do you mean my main project?

I would add it as a dependency, not peerDependency. A peer dependency makes sense when the dependent project, (e.g. an mc app, or an app I am writing) must use a certain dependency. That makes sense for react because using pyrene without react doesn't make much sense. For clsx, however, pyrene cannot and should not make any assumptions of how parent projects will build class names. Therefore this should be a dependency.

Also, please note that if we assume clsx to be provided by the parent project, it should also be externalized in webpack:

pyrene/pyrene/webpack.config.babel.js

Line 107 in a25064a

externals: ['react', 'react-dom', 'moment', 'moment-timezone'],

But, again, I really don't see the point why an application using pyrene should have to provide clsx.

[justmejulian]

@Sakai-san and @sanmiawi is this still needed or can it be declined?

[neonnoon]

@Sakai-san and @sanmiawi is this still needed or can it be declined?

If all the styleNames have been migrated, and #91 is merged, and babel-plugin-react-css-modules is removed as a dependency, I think we can kill this one.

[neonnoon]

Done with #91 (and related changes).