Can @tailwindcss/vite scan step seems to miss classes in waku

[tylersayshi]

We're seeing not all classes be picked up by the tailwind vite plugin right now. I've attached a reproduction (thanks to one of our waku users on discord). The issue in this case is that bg-blue-400 does not make it into the tailwind style output. I am able to see the className in the html output so it does seem like a bug with the plugin for now to me.

repro: https://github.com/tylersayshi/waku-vite-tailwind-bug

From this code it seems like this should auto-read from the html output, but it does seem to miss this case for now.

https://github.com/tailwindlabs/tailwindcss/blob/main/packages/%40tailwindcss-vite/src/index.ts#L187-L214

I'm happy to help however I can here :)

Update: I pushed a working example with postcss here: https://github.com/tylersayshi/waku-vite-tailwind-bug/tree/postcss

[philipp-spiess]

Thanks for the report @tylersayshi. Two quick questions:

• Is this only an issue for production builds or also for dev builds?
• Does Waku run multiple Vite builds (e.g for ssr vs client builds)?

I'm asking because the way the moudle-graph dependency scanner works has some drawbacks around production builds with SSR specifically, see this PR for some context and a proposed fix: #16425

Would love to understand if this approach would work for you!

[philipp-spiess]

Been looking into the repro and found something interesting. Apparently Waku has two different Vite builds running (I identified them by invocations of the tailwindcss() plugin function. ClientComponent1 is seen by both instances but ClientComponent2 only by the latter:

I suspect that the stylesheet is generated as an artefact of the first vite invocation sand thus the changes are not propagated.

One thing that fixes it but I'm not to sure about wether it's a good idea or not: We can move the scanned candidates into the module scope instead of the vite function scope so they are shared between all Vite runs 🤔 That fixes the issue but I'm sure it creates other ones now since the module can not be invalidated if the class is found later because it's not part of the same module tree we get the transform callback...

The PR I linked to with the file-system option also makes the issue work, which I guess is going to be the better approach here although it's unfortunate that you have to enable this option now. Perhaps there's a way to detect waku in the Vite plugin and enable this option automatically?

[tylersayshi]

Been looking into the repro and found something interesting. Apparently Waku has two different Vite builds running (I identified them by invocations of the tailwindcss() plugin function. ClientComponent1 is seen by both instances but ClientComponent2 only by the latter:

With this as the issue, we should be able to configure vite to use the tailwind plugin for both builds. We manage the vite configs for users, so we should move to including the tailwind plugin through our waku.config.ts to be sure it's always used if I am following correctly here.

Thanks for linking #16425 btw! That looks like it will help us as well, we do run SSR with RSC.

[philipp-spiess]

With this as the issue, we should be able to configure vite to use the tailwind plugin for both builds. We manage the vite configs for users, so we should move to including the tailwind plugin through our waku.config.ts to be sure it's always used if I am following correctly here.

I think that alone won't help, the issue is still that one build emits the css file but another build transforms the components.

Let me keep you posted here, we're testing some larger scale Vite changes that should resolve this as well now (basically turning on that new option from #16425 by default).

[philipp-spiess]

@tylersayshi Hey! We decided to land some changes in the Vite plugin that will ensure that both SSR and RSC builds now have access to the same class name list. We plan to release this in a patch very soon (hopefully today!). Thanks for the bug report. 🙇

[tylersayshi]

Thank you!