search

windicss / windicss-webpack-plugin

🍃 Windi CSS for webpack ⚡
https://windicss.org/integrations/webpack.html
79 stars 19 forks source link

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

Closed rlaphoenix closed 3 years ago

rlaphoenix commented 3 years ago

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: Before

After: 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 commented 3 years ago

Thanks @rlaphoenix, will try get to it tomorrow

harlan-zw commented 3 years ago

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 commented 3 years ago

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).

image

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 commented 3 years ago

Is there any update on this?

harlan-zw commented 3 years ago

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 commented 3 years ago

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