Fix watch startup build locking

[cknitt]

Motivation

rewatch watch can start while another rewatch build is running, and the two commands intentionally use separate watch.lock and build.lock files. However, watch startup still had a gap in its build locking.

The watcher acquired build.lock while running initialize_build, then released it before entering async_watch, where the initial compile happened through a second lock acquisition. That left a window where another build process could start between watch initialization and the watcher’s initial compile. Since initialization and compilation both mutate build artifacts, that gap could allow concurrent artifact writes and trigger inconsistent build output.

Changes

• Run watch startup initialization and the initial compile under the same build.lock.
• Register the initial watch paths while that same startup build state is active.
• Remove the now-unused initial_build state from the async watch loop.
• Keep subsequent incremental and full rebuild behavior unchanged, including clear-screen behavior and formatted completion output.
• Share successful watch compile completion handling for initial, incremental, and full watch builds.

Covered cases

This now protects the startup path where:

• rewatch watch performs initialize_build
• initial source folders are discovered and registered
• the watcher performs its initial compile
• another rewatch build is already running or starts at the same time

The existing full rebuild path remains protected by build.lock, including rebuilds triggered by config changes, rename events, and editor atomic-save behavior.

[cknitt]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

rescript/rewatch/src/watcher.rs

Lines 589 to 593 in 2c247a8

	if let Ok(result) = build::incremental_build_without_lock(
	&mut build_state,
	None,
	true,
	show_progress,

Prevent duplicate compile after startup initialization

This new startup path performs an initial compile inside start, but async_watch still begins with needs_compile_type = CompileType::Incremental, so watch mode compiles twice on launch (initial + immediate incremental with no file change). That doubles startup work and can run --after-build twice before any edit, which is a behavior regression for all watch sessions.

---

rescript/rewatch/src/watcher.rs

Lines 598 to 600 in 2c247a8

	finish_successful_watch_compile(
	after_build.clone(),
	timing_total,

Run after-build hook outside build lock

finish_successful_watch_compile is invoked while still inside with_build_lock during startup, and that helper executes cmd::run(after_build). If the hook launches another ReScript build command, it will contend on build.lock while the parent still holds it, causing a wait/timeout cycle instead of running immediately. The same hook runs outside the lock for incremental/full rebuilds, so startup now behaves inconsistently and can hang user hooks.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[pkg-pr-new]

Open in StackBlitz

rescript

npm i https://pkg.pr.new/rescript@8413

@rescript/darwin-arm64

npm i https://pkg.pr.new/@rescript/darwin-arm64@8413

@rescript/darwin-x64

npm i https://pkg.pr.new/@rescript/darwin-x64@8413

@rescript/linux-arm64

npm i https://pkg.pr.new/@rescript/linux-arm64@8413

@rescript/linux-x64

npm i https://pkg.pr.new/@rescript/linux-x64@8413

@rescript/runtime

npm i https://pkg.pr.new/@rescript/runtime@8413

@rescript/win32-x64

npm i https://pkg.pr.new/@rescript/win32-x64@8413

commit: bdc7a2f