Public API for pre-rebuild veto or watcher substitution in Turbopack (dev)

[GriffinCanCode]

Summary: Turbopack currently offers no public JS seam to observe which files changed in a watch pass, to substitute the underlying file watcher, or to veto a rebuild before it runs. turbopack.rules covers per-file loaders only. This blocks an entire class of dev-tooling — content-addressed watchers, no-op-write suppression, custom notification backends (e.g. Watchman on large monorepos, polling on network filesystems) — that webpack supports today via a settable compiler.watchFileSystem and that Vite supports via server.watcher + handleHotUpdate.

Request: Expose one of (in order of preference):

1. Pre-rebuild veto — a hook invoked with the changed path(s) before Turbopack schedules a rebuild, whose return value can suppress the rebuild for a given path. This is the smallest surface that expresses "these bytes are identical; do nothing."
2. Watcher substitution — a documented way to supply the file watcher Turbopack consumes (analogous to webpack's settable compiler.watchFileSystem), so an external watcher can be the sole source of change events.
3. Change observation + invalidation — a hook that reports which paths changed in the current pass and an API to programmatically invalidate a path, so an integration can watch itself and drive invalidation only for real changes.

Any one of these unblocks the integration. (1) is the smallest.

Use case: We maintain a native content-hashing watcher that skips byte-identical rebuilds (a formatter-on-save, a generator that reran, a branch switch that restored identical contents). It integrates with webpack (watchFileSystem), Vite, Rspack, Rollup, and esbuild. Turbopack is the only major bundler with no attachable seam, so Next.js users on Turbopack cannot get no-op-write suppression today and must fall back to bundler: 'webpack'.

Prior art: webpack compiler.watchFileSystem; Vite server.watcher + handleHotUpdate; Rspack compiler.watchFileSystem compatibility.

---

Filed as a Discussion because this is an API/feature request, not a bug: the bug-report issue form (#96520) is auto-closed for lacking a reproduction. Happy to move this to an RFC if that is the preferred venue for a public-API proposal.

[GriffinCanCode]

Built a runnable reproduction of the gap: https://github.com/GriffinCanCode/turbopack-noop-write-repro

One Next.js 16.2.12 app, eight byte-identical writes to app/page.jsx, three arms:

Arm	Byte-identical writes rebuilt	Real edits rebuilt
next dev --webpack + watchFileSystem seam	0 / 8	2 / 2
next dev --webpack, stock watcher	8 / 8	2 / 2
next dev --turbopack	8 / 8	2 / 2

npm install && npm run measure runs all three in about 75 seconds. Rebuilds are counted from Next's own HMR channel ({"type":"building"} frames on /_next/webpack-hmr), not from watcher events, so every counted rebuild is one the dev server actually ran. The two real edits per arm are there so suppression can't pass by simply breaking HMR.

The whole webpack-side integration is about thirty lines wrapping compiler.watchFileSystem. The Turbopack arm keeps the identical webpack key in next.config.mjs, where on 16.2.12 it is ignored with no warning, so the failure is quiet: the same config that removes eight rebuilds under one flag removes none under the other.

Two details from building it that bear on which API shape is best:

1. NodeWatchFileSystem registers its aggregated listener with once, and webpack only calls watch() again after a rebuild finishes. Veto the rebuild and nobody re-arms the watcher, so the integration has to re-arm it. A first-class pre-rebuild veto wouldn't put that on the caller, which is why option 1 above still looks better to me than option 2 even though option 2 is the one with existing prior art.
2. Turbopack does not already skip byte-identical writes internally, so this isn't redundant with an existing optimization; the eight rebuilds are real.

Happy to reshape any of this into an RFC, or to cut the repro down further if it's more useful smaller.

[GriffinCanCode]

Implemented it: #96575

Opt-in behind TURBO_TASKS_SUPPRESS_UNCHANGED_WRITES=1, off by default. On a hello-world app built from that branch, 20 byte-identical writes go from 20 update cycles to 0, and real edits still rebuild 3/3 with serverComponentChanges. Eight unit tests in watcher.rs cover the cases that must never be skipped: creates, removals, renames, symlinks, permission changes, the first write after startup, and anything unreadable.