This PR removes all of the custom HMR handling we had in the `@tailwindcss/vite` plugin. When Vite 7.1 was introduced, Vite stopped performing a full page reload for unknown files and instead started performing normal `hmr` updates. This resulted in this issue: https://github.com/tailwindlabs/tailwindcss/issues/19637 At the time, it felt like something we could easily re-add: if a file is not covered by Vite, we can perform a `full-reload`. This meant that a `.php` file would trigger a full page reload as expected. The reason the `.php` file triggered Vite in the first place is because those files were scanned by us (`@tailwindcss/vite`) so it made sense. However, this then resulted in a plethora of issues, and it feels a bit like a game of whac-a-mole. - https://github.com/tailwindlabs/tailwindcss/issues/19744 - https://github.com/tailwindlabs/tailwindcss/issues/19903 - https://github.com/tailwindlabs/tailwindcss/issues/20320 - https://github.com/tailwindlabs/tailwindcss/issues/20378 - https://github.com/tailwindlabs/tailwindcss/issues/20411 Fixes: #19744 Fixes: #19903 Fixes: #20320 Fixes: #20378 Fixes: #20411 We kept updating the logic by safelisting certain extensions, checking different servers and/or environments, handling the fact that `server` in the callback could be absent in `experimental.bundledDev` mode, etc. etc. Now, when investigating the last issue (https://github.com/tailwindlabs/tailwindcss/issues/20411), I can trigger full reloads by changing `.json`, `.yaml` or `.svg` files. This makes sense since they aren't handled by default. So thinking about this more, I think it's just not Tailwind's responsibility to tell Vite to reload the browser or not. Yes, we use the `addWatchFile` API, so files are being watched because of us. However, our only goal is to update the `.css` file (and HMR that). This means that we can just drop all the custom HMR handling we have in `@tailwindcss/vite`. This also means that https://github.com/tailwindlabs/tailwindcss/issues/19637 would regress and won't trigger full page reloads. But this can be easily handled by a plugin responsible for this behavior: - https://github.com/ElMassimo/vite-plugin-full-reload ## Test plan 1. All tests pass 2. Manually tested and changing unknown files don't result in a full page reload |
||
|---|---|---|
| .. | ||
| src | ||
| package.json | ||
| README.md | ||
| tsconfig.json | ||
| tsup.config.ts | ||
A utility-first CSS framework for rapidly building custom user interfaces.
Documentation
For full documentation, visit tailwindcss.com.
Community
For help, discussion about best practices, or feature ideas:
Discuss Tailwind CSS on GitHub
Contributing
If you're interested in contributing to Tailwind CSS, please read our contributing docs before submitting a pull request.
@tailwindcss/vite plugin API
Enabling or disabling Lightning CSS
By default, this plugin detects whether or not the CSS is being built for production by checking the NODE_ENV environment variable. When building for production Lightning CSS will be enabled otherwise it is disabled.
If you want to always enable or disable Lightning CSS the optimize option may be used:
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
plugins: [
tailwindcss({
// Disable Lightning CSS optimization
optimize: false,
}),
],
})
It's also possible to keep Lightning CSS enabled but disable minification:
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
plugins: [
tailwindcss({
// Enable Lightning CSS but disable minification
optimize: { minify: false },
}),
],
})