CLI Watch never end 2 CPU cores at 100% #17246
Comments
|
I encounter the same problem with:
|
|
Hey! I tried running your example on macOS and it works fine (I tried with your exact Node version and v22 (what I had installed before): 
Going to try this out on Windows 11 later too, but I wonder what happens if you run the
This is expected for the |
|
With DEBUG=1, there is no output and 2 cores at 100%. |
|
I got the same result with Node.js v22.14.0 (npm 10.9.2). |
|
I tried on another windows (v10). It works |
|
Tailwind CSS seems to be incompatible with the Watchman (Meta) software. If I delete the shim-generated file: This suggests that Tailwind CSS is likely using Watchman in the background for file watching. When it launches the 2025 version found in the PATH (the one installed via Chocolatey), it may trigger unexpected behavior (infinite loop?). |
|
I see on @parcel/watcher:
A log about the watcher used or a compatibility check on the version could be a plus to facilitate problem identification. |
|
@deguich Hey! Thanks for digging into it. Are you able to reproduce the problem when using |
|
I'm experiencing same problem on Mac M2 using Node v22.14.0 and Yarn 1.22.22. When running I get the same issue when running on host OS using Node v23.7.0 (different than dockerized), yarn 1.22.22. |
|
I can confirm that locking version at npm install @tailwindcss/cli@4.0.15
npx @tailwindcss/cli -i app.scss -o app.css # builds |
|
I can reproduce what seems to be this issue when I have watchman installed; and it goes away when I uninstall watchman. With watchman installed, on a Linux x86_64 GNU libc system (native, not in a container) running with The initial startup takes 81 seconds. After that startup, everything seems responsive and changes to files result in: Without watchman installed, though, startup is 1000x faster: |
|
This was happening to me on Node |
|
This is happening to me in 22.14.0 too. 197% CPU usage always. I use mac m1 |
|
@flavorjones What specific versions of 
I tried it with both the latest standalone build and with the latest CLI and Node.js @silva96/ @ChadMoran Was your issue also |
|
@deguich Can also not reproduce the issue on Windows 11 Node 20 I'm afraid:
Maybe this requires a very specific version of watchman to trigger? |
This comment has been minimized.
This comment has been minimized.
|
@philipp-spiess Thanks for looking into this. I reproduce this consistently on:
Here's a full console log that might be helpful to see what's going on and potentially reproduce. Note that the tailwindcss CLI is installed via the tailwindcss-ruby gem, but it's simply the precompiled executable shipped by the tailwindcss project -- the full command is included below. |
|
@flavorjones Hmm this is getting bizarre. I just provisioned a new VPS with your repro and still can't reproduce this: I wonder if this happens with plain apt install nodejs npm
mkdir test
npm init
npm add @parcel/watcher
# paste in the content below into index.js
node index.js
# in different session
touch index.jsconst watcher = require("@parcel/watcher");
watcher.subscribe(".", async (err, events) => {
if (err) {
console.error(err);
return;
}
console.log(events);
}).then(console.log);For me this immediately logs the unsubscribe function and also logs updates immediatly: |
|
Looking at the implementation a bit, I wonder if it works if you set https://github.com/parcel-bundler/watcher/blob/master/src/watchman/WatchmanBackend.cc#L44C22-L58 WATCHMAN_SOCK=/dev/null node index.js |
|
@philipp-spiess A thing I noticed is that watchman, when run, spins up a daemon that runs in the background for subsequent runs (I think? I'm not very familiar with the tool). This issue -- the long initial build step -- only seems to happen when the daemon is not already running. If the daemon is running already, it's fine: That said, if the daemon is not running and I set |
|
Yeah so it seems that for me, too, watchman is slower when it boots up the first time. However that's 1 second and not 80s 😬 
I've been playing a round a bit to figure out how the watchman CLI works in order to be able to test this independelty from tailwind and watchman shutdown-server
watchman watch-del-all
watchman --persistent log-level debugAnd in the other terminal I wonder specifically if these startups log and that initial crawl are stuck for you there too! Thanks for your patience on this by the way, really appreciated! |
|
@philipp-spiess I think I understand what's going on here. First: I did as you asked, and ran these commands in two different terminal sessions in the Rails project directory. Nothing seems to be hanging for me. The logs seem to show immediate responsiveness, and when I touched a local file ("README.md") saw it immediately show up in the logs. Here's the output from the debug command, in case it's useful: watch.log Same result if I run the tailwindcss watch command after the Then I shut down watchman, ran the tailwindcss watch command again, and then turned on logging. I saw some interesting entries in the logs related to "bootsnap" files like: Bootsnap is a library used by default by Rails to pre-parse and pre-compile Ruby code to speed up process start time. For this demo app, it generates 1600+ files spread across a nested directory hierarchy: Playing around with it, I can turn off bootsnap but so long as those files are present, the tailwindcss watch command startup is slow. I think this behavior is related to this issue: #15750. Because the watch command should not be looking at files in the |
|
@flavorjones Ah yeah that is very helpful. It does seem like a blanked listen for all changes in this directory recursively won't cut it, which is annoying because One option I am looking into is the ignore list now. We may be able to compute something for that in Oxide but before we go ahead and try that, I'd love to understand if this fixes your perf issues. Can I ask you for one more favor here? Try the following parcel script and let me know if the inclusion of that ignore option makes any difference: const watcher = require("@parcel/watcher");
watcher
.subscribe(
".",
async (err, events) => {
if (err) {
console.error(err);
return;
}
console.log(events);
},
{ ignore: "./tmp" }
)
.then(console.log); |
|
I tried starting the rails app in my repro Linux VM but even though my So I naturally duplicated the 
Now let me try if that ignore setup would work. |
It doesn't seem to make a difference for me. It takes about 1m32s with or without the ignore parameter. |
What version of Tailwind CSS are you using?
v4.0.14
What version of Node.js are you using?
v20.18.0
What operating system are you using?
Windows 11
Reproduction URL
I just use the Tailwind4 directory of https://github.com/pinzonjulian/tailwind_css_cli_watch_bug.git
Describe your issue
Command never end, there is no output, 2 cores at 100%.
If I remove output.css, the process don't create it.
When I remove --watch.
It works :
Could a global configuration be the cause of the problem?
The text was updated successfully, but these errors were encountered: