-
-
Notifications
You must be signed in to change notification settings - Fork 6.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slow HMR due to tailwind jit #11652
Comments
I think this is mostly caused by a perf regression in tailwind, fixed in insiders by tailwindlabs/tailwindcss#10234 |
Hi! This is "normal" to have an HMR of tailwind for every file matched by Tailwind content. This is because Tailwind is not build for this kind of devtooling. This is one of the motivation behind UnoCSS (and my personal implementation). How big is your project? I've worked on project with recent version of Tailwind (3.2) and hundred of components without seeing any perf issue. |
My tailwind/vite setup had 2-4sec hot reload time. Fixed it by changing double asterisk into single inside tailwind config content selector. This was slow: This is instant: |
That resolved my headache, thanks a lot!! I solved it be removing the statement for .js files, as I didn't need them to be watched. So the proposed solution has led me to a solution, but isn't a "real" solution. |
Using one start means you're only scanning folder with depth 1, this is not a real fix. |
I'm seeing same thing even after tailwindlabs/tailwindcss#10234 which helped a lot (I'm using version 3.2.6), especially when running vite inside docker container on macOS as a host where I'm getting ~15 seconds long HMRs. Once I remove Tailwind import, HRM becomes instant. |
I meet this problem and I solved it by setting more precise matching rules. module.exports = {
content: ['./*.html', './src/**/*.{js,jsx,ts,tsx}']
} |
Your answer helped me a lot, thanks! |
Hey, reminder that this is a dangerous fix, because any file with depth > 2 will not be scanned |
@ArnaudBarre do you think that there is something Vite could do to help here? If not, I think we could close this PR in favor of Tailwind reviewing if they could change something on their side to better integrate with Vite, no? |
Yeah I still don't have a repro. Personally I worked on a project with hundred of files in Tailwind globs (tens of thousand of lines in total) and HMR was still largely subsecond for CSS (mac intel). The example is also using scss for Plus I fixed the double HMR log in Vite 4. Even if I think Tailwind could do a lot better in perf with an API a lot more friendly for dev server, I'm still to be proven that they are the issue in slow apps and not a Babel plugin or a CSS transformer |
Describe the bug
I'm using the new
@vitejs/plugin-react-swc
and hooking up HMR.I've created a new project within a large monorepo. I'm using tailwind, and the tailwind purge rules apply to the entire monorepo.
HMR is working, but I'm seeing that every time I reload a component, the file that is importing tailwind is also rebuilding. Because of the monorepo size, the tailwind part is taking 4s.
The component doesn't reload until the tailwind part has recompiled. I'm wondering if it should maybe separate the two operations into two hmr events rather than trying to reload both in one transaction?
https://stackblitz.com/edit/vite-react-tailwind-pfgspw?file=src%2FApp.jsx,src%2FExample.jsx
Reproduction
https://stackblitz.com/edit/vite-react-tailwind-pfgspw?file=src%2FApp.jsx,src%2FExample.jsx
Steps to reproduce
Edit example.jsx and change the contents. While there is no tailwind affecting stuff in this component, it will still trigger an HMR of the tailwind CSS file.
System Info
Used Package Manager
yarn
Logs
Click to expand!
Validations
The text was updated successfully, but these errors were encountered: