[NextJS] Page WindiCSS being removed on next page build if any change occurred in next dev

[rlaphoenix]

Describe the bug
When I change something in a page, be it some JSX, className value, some text, anything, the CSS stops working, and never recovers. It seems to occur whenever ANY sort of page gets built after an edit is made, prior to the page build. It doesn't even have to be a user-made page in /pages. It can even be the build page: /next/dist/pages/_error.

To Reproduce

1. Clone repository https://github.com/windicss/windicss-webpack-plugin
2. Run npm run dev:nextjs
3. Edit example/next/pages/index.jsx and change the top "Should be Yellow" to "Should be Yellow123". Hit save and see the change appear.
4. Go to any other page (force a 404 if needed, this works too, but do Step 2 to 4 quickly before it prebuilds).
5. Now go back to https://localhost:3000 and see the "Should be Yellow123", notice how it's clearly white BG and black text, default font-family, and the rest of the page is seemingly relatively blank CSS.

Expected behavior
The CSS should still have applied like normal.

Screenshots
Before:

After:

Additional context
Even refreshing the page multiple times, going back and forth between pages, etc. won't do anything. Only fix? Stop and restart the next dev.

[harlan-zw]

Thanks @rlaphoenix, will try get to it tomorrow

[harlan-zw]

Hey @rlaphoenix

I was able to replicate this issue, it was a pretty annoying one to try and fix but I think I may have a 'bandaid' solution. Basically, we invalidate the module with the full source so that HMR's can't trigger broken virtual module states.

Would you mind doing some testing on 1.3.0 to see if you can replicate it or if it causes new problems?

[rlaphoenix]

Hey @rlaphoenix

I was able to replicate this issue, it was a pretty annoying one to try and fix but I think I may have a 'bandaid' solution. Basically, we invalidate the module with the full source so that HMR's can't trigger broken virtual module states.

Would you mind doing some testing on 1.3.0 to see if you can replicate it or if it causes new problems?

1.3.0 does seem to fix the problem where it resets the CSS and goes blank, but it doesn't ultimately fix the problem. It doesn't reset the CSS when you follow the reproduction steps, but it does not add any new CSS changes either when you change/remove/add a className for example.

I think this may not have been spotted since the example code only has one page, and for this bug to occur you need to have the change written before the specific page with that change builds (in that case, before the first time you access the page).

This little box is my prime example here. It should be bg-red-400, but instead, it's white. The class name change is there, but the CSS seemingly has no class bg-red-400 in its generated file. This is all because I changed bg-blue-400 to bg-red-400 before NextJS built /tv on my project for the first time.

To reproduce this specifically:

1. Follow steps 1-2 on the OG post.
2. Create a new page, e.g. pages/test.jsx with a <div className="bg-blue-400">Test</div>.
3. npm run dev and go to https://localhost:3000 (not /test yet).
4. Change some windicss in pages/test.jsx, like the bg-blue-400 to bg-red-400.
5. Now navigate to https://localhost:3000/test and you will see it is in fact no longer bg-blue-400, but it also has bg-red-400 that isn't actually taking place, as it isn't in the generated windicss.

I should be clear here. The initial CSS change you make has to be any Windi CSS-related change, e.g. className. The change has to be to a CSS that has not yet been used anywhere else in the pages that are built because the CSS code would already be in the generated CSS that reaches the browser. We need to have it add something NEW to the virtual windi.css if that makes sense.

Unlike the initial bug, it's possible to recover from this state. Simply build the page once, and THEN make your changes and it works fine. You could also fix the broken change by just changing or adding any kind of other CSS, saving, letting Next compile, and then remove the change or addition. Not ideal of course, but it's way less annoying than the original bug at the very least.

[rlaphoenix]

Is there any update on this?

[harlan-zw]

Hey @rlaphoenix

Thanks again for the detailed issue and patience. I dived into the issue to try and find the problem, it seems it was around the invalid hooks in webpack5 reporting null entries.

What it will now do is when it detects these null entries, it will re-scan all your files when generating the virtual module.

Can you try with 1.4.0 and confirm the issue is resolved?

[rlaphoenix]

Amazing, it seems to work as expected now. Thank you!