Repository navigation
Conversation
 [Medium impact] The PR appears safe to merge. Reviews (1) · Last reviewed commit: "fix: retain synchronous scanning on unsu..." · Reviewed by Greptile |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
WalkthroughParallel walking now runs only after an initial scan and only on Unix or Windows. Other targets use synchronous walking. A Linux-only integration test checks that repeated wasm scanner scans preserve results for unchanged files, detect modified files, and discover new nested files. Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation |
|---|---|---|
| Title check |  |
The title clearly identifies the main change: fixing incremental source scanning for WASI. |
| Linked Issues check | |
Check skipped because no linked issues were found for this pull request. |
| Out of Scope Changes check | |
Check skipped because no linked issues were found for this pull request. |
| Description check | |
The pull request description directly explains the WASI scanner fix, the platform-specific traversal behavior, and the added regression test. It matches the changeset. |
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands.
Summary
Fix incremental source discovery in the WASI scanner.
This surfaced in a Vite dev server running inside WebContainer, which uses the WASI binding. Changing a utility class in JSX (for example,
bg-red-600tobg-blue-600) updated the markup, but the new utility was missing from the generated CSS. The filesystem change event arrived and Vite reran the Tailwind CSS transform, yet the reused scanner no longer reported the source files or discovered the new class.Touching the stylesheet, even by adding a comment, made the missing styles appear because it caused Tailwind to recreate the scanner. A fresh production build also generated the expected CSS. The issue was reproduced independently of Vite and WebContainer by reusing the WASI scanner in a standalone Node.js process.
The first scan uses synchronous directory traversal, but subsequent scans switch to the parallel walker. In the vendored
ignorecrate, the parallel walker's directory-entry constructors returnunsupported platformon targets other than Unix and Windows. Those errors are skipped, so subsequent scans lose the discovered file list and fail to detect changed or newly added files while continuing to return cached candidates.Keep synchronous traversal on those targets. Unix and Windows retain the existing initial-synchronous/subsequent-parallel strategy. This changes directory traversal only; the scanner's other parallel processing paths are unchanged.
Add a WASI regression covering an unchanged rescan, an edited source file, and a newly added nested source file. Explicit modification times avoid depending on filesystem timestamp resolution or sleeps.
Test plan
cargo test -p tailwindcss-oxide— 196 tests passed.pnpm --filter @tailwindcss/oxide run build:wasm— rebuilt the release WASI binding.index.htmland later scans missed edits and additions. After the fix, all four scan states retained the expected files and candidates.cargo fmt --package tailwindcss-oxide -- --check— passed.pnpm exec prettier --check integrations/oxide/wasm.test.ts— passed.The new integration test follows the existing Linux-only WASI test gating. Its scanner lifecycle was exercised directly on macOS; the packaged integration suite was not run locally.