Symlink support on new watcher#13707
Merged
nachocodoner merged 9 commits intorelease-3.3from Apr 30, 2025
Merged
Conversation
✅ Deploy Preview for v3-meteor-api-docs canceled.
|
zodern
reviewed
Apr 24, 2025
zodern
reviewed
Apr 24, 2025
This was referenced Apr 30, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Continues: #13699
This PR addresses part of the feedback from @zodern in the previous PR. It improves support for symbolic links by detecting symlinks and all traversed files, using a polling strategy to reliably watch for changes. I also enabled support for direct packages linked with npm link in the project's node_modules. I tested these and they work well.
Polling is used because native recursive watching isn't supported consistently across all OS when using symlinks, so polling is applied in these cases. Tools like chokidar could handle this more smartly, but for now this approach works well enough.
I considered enabling native watching and polling for all project files simultanously, not just symlinks. However, polling puts significant load on the CPU and impacts performance. So for now, polling remains opt-in via an environment variable (
METEOR_WATCH_FORCE_POLLINGandMETEOR_WATCH_POLLING_INTERVAL_MS).Most modern bundlers rely on native watchers, and for edge cases like working with volumes or network files, you can opt into polling. See Vite and rspack as examples. This favors performance in common scenarios while keeping compatibility available when needed.
Since Meteor 3.4 will favor using a modern bundler for app and node_modules code, it makes sense to align with how they handle things. As app code will be managed by the bundler, its options will become the new configuration standard for modern Meteor apps, including watching. Using
@parcel/watcherstill makes sense on Meteor core, as it improves file change detection for atmosphere packages code and intermediate outputs from the modern bundler.We'll mention in Meteor 3.3 that this could be a breaking change in cases like using WSL2 from host machine, working with volumes, or over network setups, where polling needs to be enabled manually. I'll test some of these cases too. It’s also a chance to collect feedback, but since performance is the priority, and this aligns with other modern tools, this seems like the right path.