No description
39656f7d9a
This PR re-adds the `--poll` option to the `@tailwindcss/cli` that we had in Tailwind CSS v3, but didn't in Tailwind CSS v4. In Tailwind CSS v4, we started using `@parcel/watcher` instead of chokidar for our watcher in the CLI. However, this currently doesn't support a `--poll` option. This PR implements our own `--poll` option such that you can use it in environments where fs events don't work properly (e.g. Docker). Polling can be enabled by using `--watch --poll`, in this case we will poll every `250ms` (I'm open for a different default value). You can also pick your own interval by using `--watch --poll 500` which is defined in milliseconds. The `--poll` option will be less efficient than a normal `--watch`. But if you are in a situation where you can't use `--watch` on its own then this is a good fallback. One thing you can do today is run the build command manually. If you do have some tooling that _does_ work on your machine (such as [`watchexec`](https://github.com/watchexec/watchexec)) then you can automatically perform a full build. The biggest downside of this approach is that you are doing a full build every time, instead of an incremental build. With this PR, we try to fix that by still allowing incremental builds. This should result in the same behavior as the normal `--watch` function: 1. First run, will trigger a full build 1. When any of the source files changes: - If all classes were already known, then it will be a no-op, but you will see a log in the terminal about it. - If a new class is detected, then the CSS will be updated, but it will be much more efficient than a full rebuild 1. When the input CSS file changes, or any of its dependencies, then a full rebuild will be triggered (such that your new `@utility` are available, and `@theme` values are updated). The implementation is a little bit more complex just because I didn't want to spam the terminal output even if we are polling every `250ms`. In the Oxide scanner we do track the modified times of each file. Every `250ms` we traverse the file system and skip the files that we know didn't change (since the mtime is the same). If the file was touched, then we will parse it again to extract possible Tailwind CSS classes. We will also track which files were scanned such that we can know whether we have to trigger a full-rebuild or not (in case the input.css file or any of its dependencies was changed). Fixes: #18109 Fixes: #18540 Fixes: #15750 ## Test plan 1. Existing tests pass 2. An integration test has been added for the `--poll` option 3. Tested it on the tailwindcss.com codebase: <img width="679" height="320" alt="image" src="https://github.com/user-attachments/assets/af858da5-3e07-448d-86bd-8eacdf3bf8d1" /> Annotated: ``` ≈ tailwindcss v4.3.2 Done in 105ms Initial build Done in 3ms Saved a file that resulted in a no-op Done in 2ms Saved a file that resulted in a no-op Done in 3ms Saved a file that resulted in a no-op Done in 53ms Saved a file with a new class Done in 2ms Saved a file that resulted in a no-op Done in 2ms Saved a file that resulted in a no-op Done in 3ms Saved a file that resulted in a no-op Done in 88ms Saved a the input.css file Done in 3ms Saved a file that resulted in a no-op Polling for changes… ``` We check the file system every `250ms` by default, but we won't log to prevent spamming the terminal. |
||
|---|---|---|
| .github | ||
| crates | ||
| integrations | ||
| packages | ||
| patches | ||
| playgrounds | ||
| scripts | ||
| .gitignore | ||
| .prettierignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CHANGELOG.md | ||
| LICENSE | ||
| package.json | ||
| pnpm-lock.yaml | ||
| pnpm-workspace.yaml | ||
| README.md | ||
| rust-toolchain.toml | ||
| turbo.json | ||
| vitest.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.