-
Notifications
You must be signed in to change notification settings - Fork 81
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 startup in monorepo #276
Comments
I am working on this this week/month (time permitting) actually! The immediate issue seems like a regression in ignores but there's other deeper issues that I'm working to eliminate. As a workaround for right now you can try using |
Sorry to say that didn't seem to help. I also added some other big directories like What does help for now is Also possibly relevant is that the main cargo.toml has [workspace] with several members. Some output (before using --no-vcs-ignores):
Let me know if anything else in the output might be interesting. |
Ahhh yep, different regression, also on the todo list but a bit further down. Glad you've got a workaround tho! |
I'm running into the same issue. Passing A sample of the logs:
The Any progress on this is appreciated. 🙏 |
Another thing I noticed while trying to debug this myself (before finding the workaround here), we seem to be opening files in the ignored directory even though they will never cause an execution.
Prints tons and tons of:
Despite all of the above folders being ignored by multiple criteria. |
Yeah, the core issue here and still in watchexec is that the notify library does the recursion for the actual watching, and it's not aware of ignores/filtering, so it goes way beyond where it should look. Watchexec has a work item pending (I've been on a break/holiday, will start work on it in 2024Q3) to do the recursion in the watchexec library, this time with awareness of ignores. That should solve the remaining startup performance issues, at which point I'll get cargo-watch over too. |
I am trying out cargo watch in a monorepo which is made of node, rust, etc. and it takes a long time (~50 seconds) to start
cargo watch -x test
. Turning on--debug
it looks like it is watching the whole repo (node_modules, etc). I've tried--skip-local-deps
and-w .
but it still seems to be watching much too widely. Any other options I can try?I'm running it straight on a mac m1, no docker or anything, happens in both iterm2 and jetbrains (goland) embedded terminal.
The text was updated successfully, but these errors were encountered: