schoero / eslint-plugin-readable-tailwind

ESLint plugin to automatically break up long tailwind class strings into multiple lines for better readability.
MIT License
93 stars 3 forks source link

feat: tailwindcss v4 #25

Open schoero opened 5 months ago

schoero commented 5 months ago

Continuation of #18

Add support for tailwindcss v4.

schoero commented 5 months ago

Status update

cc: @zcf0508

There were (and still are) some issues making this plugin compatible with tailwindcss v4.

TODO

zcf0508 commented 4 months ago

I was inspired to create the feature from https://github.com/hyoban/tailwindcss-classname-highlight/blob/main/src/index.ts#L78, and wish this is helpful for you to resolve the problem.

For now, I think we can publish an alpha version for v4 users, as tailwind v4 has not been release. Or we can release two versions that one for v3 and one for v4 to prevent code coupling and enhance clarity.

schoero commented 4 months ago

My current branch doesn't yet work with tailwindcss v4 because I couldn't yet figure out how to resolve the @import statements in the css files.

I think the approach taken in https://github.com/hyoban/tailwindcss-classname-highlight is pretty hacky as it just reads all css files and creates the tailwind context from them. There is no resolving of import statements and the tailwind internals and it also includes css files that may not be intended for tailwindcss.

The same problem exists in the branch you created for #18.

I got pretty deep into a rabbit hole trying to resolve this problem and I have posted my findings in my comment above.

In the anouncement blog post, they wrote about integrating lighntingcss and automatically handle those problems.

In their codebase as it is right now, they have not done this integration yet and they still rely on postcss, which is not an option for eslint plugins, because postcss-import is async.

The plan is now to wait for tailwindcss v4 to be more mature and let them figure out the solution to this problem. Any additional effort I put into this right now will eventually be wasted time in the long run and this is not sustainable for me right now.

What I can do prior to this, is to make the plugin work with v4 in a way that it no longer crashes. The sort-classes rule is the only rule that depends on tailwindcss internals. I can refactor the plugin so that the tailwind internals are not loaded until they are used.

If you disable the sort-classes rule, or change the order to asc for example, there would be no need to load the tailwind internals and the plugin would therefore not crash.

I have done a lot of preparation work in #26 for this.

schoero commented 4 months ago

I created a feature request in lightningcss for synchronous custom resolvers: https://github.com/parcel-bundler/lightningcss/issues/747