Summary

Fixes concurrent node_modules corruption when multiple Deno processes run in parallel against the same project (nodeModulesDir: "auto"), reported in #35804.

node_modules setup is guarded by LaxSingleProcessFsFlag (libs/npm_installer/flag.rs), which combines an OS file lock with a poll-file heartbeat so waiters can detect a lock holder that was killed without releasing the lock. A waiter concluded the holder was dead once the heartbeat went stale for just 200ms (2× the 100ms update interval) and then proceeded without the lock.

Under parallel installs of native --allow-scripts packages (notably on Windows), a busy but perfectly alive holder — spawning compilers/node-gyp, creating junctions, renaming files — can easily miss that 200ms window. Every waiter then falsely concludes it died and mutates node_modules concurrently, corrupting the tree. This matches the report's fingerprint: users see "Blocking waiting for file lock on node_modules directory" (the lock is working) and corruption at the same time (os error 3 junction failures, EBUSY renames, half-installed native addons, flaky ERR_MODULE_NOT_FOUND).

Heartbeat starvation isn't the only way to trip a 200ms margin:

• The heartbeat write itself can silently fail — PollFile::touch() ignores write errors — so antivirus interference or a transient EBUSY on Windows stalls the poll file's mtime without the holder ever knowing. Two consecutive failed writes were previously enough to cause false preemption.
• Coarse filesystem mtime granularity (2 seconds on FAT/exFAT) could exceed the old threshold all by itself.

The 5s margin comfortably covers all of these.

Change

• Widen the staleness threshold from 200ms to 5s.
• Pull the two timing values into named constants (POLL_FILE_UPDATE_INTERVAL_MS, POLL_FILE_STALE_THRESHOLD_MS) with a comment explaining why the margin must be generous.

OS file locks are released automatically when a process exits, so this poll check only needs to backstop the rare case of delayed release — it can afford a generous margin. The same lock is used by both the local (.deno layout) and hoisted installers, so both are covered.

Notes

• No automated test: the bug only reproduces under real heartbeat-thread starvation, which isn't deterministic without refactoring the staleness decision into an injectable function — a wall-clock test would be flaky. Existing flag:: lock tests still pass.
• A follow-up is worth considering: a read-only fast path so already-initialized node_modules skips mutation/lock contention entirely in child processes (also helps the startup-cost report in skip/background package check when booting with autoinstall & lock: false #35761). Left out of this PR to keep it focused on the correctness fix.
• Known residual behavior: when preemption fires for a genuinely dead holder, all waiters cross the threshold within the same ~20ms polling window and proceed concurrently — the wider margin makes false preemption rare but doesn't serialize the true-positive case. Acceptable for now (the lock is "lax" by design); could be improved alongside the fast-path follow-up.

Refs #35804