Rollup plugin cache vs full rebuilds for zero-downtime migration of a small app

Disable caching and run full rebuilds on both sides. For a small application, that is the lower-risk option, and the reasoning is simpler than the plugin audit you were planning: Rollup's incremental cache cannot help you during a migration anyway.

Why the cache question mostly dissolves

Rollup's incremental behavior is an in-memory structure that lives inside a single process — either a long-lived --watch session or a programmatic build that reuses the same Rollup instance. It is never written to a portable, shareable form. Your old and new servers would each maintain independent caches regardless, so there is no cache state to migrate, sync, or invalidate across the cutover. The cache only affects how fast a rebuild is within one environment, not whether two environments agree.

The real risk of inconsistent artifacts during parallel builds is nondeterministic inputs: different plugin versions resolved from an unpinned lockfile, differing environment variables, or different file states on the two machines. Those produce divergent output even with caching fully disabled — and conversely, with identical inputs, a full build is deterministic regardless of cache state. So the effort belongs on input parity, not cache auditing.

Correcting one assumption

Cache participation is not governed by the buildStart hook. A plugin opts out of watch-mode caching by setting cache: false on the plugin object itself, and it influences invalidation through this.addWatchFile when its transform/load results depend on external files. Auditing buildStart/buildEnd implementations would target the wrong mechanism.

Is there a documented inspector?

No. There is no CLI flag or API that lists which plugins opt out of caching. The practical audit, if you ever need it, is grepping plugin sources:

grep -rn "cache: false" node_modules/ --include="*.js" | grep -i rollup
grep -rln "addWatchFile" node_modules/

Note that a plugin lacking cache: false is not automatically safe — hooks that read undeclared external state (env vars, files outside the module graph) can still go stale in watch mode.

Watch mode vs programmatic builds

Yes, the difference matters, but it simplifies your decision rather than complicating it. Watch mode persists the module graph across rebuilds, which is where incremental work and all the plugin-cache subtleties live. A one-shot programmatic build via rollup.rollup(inputOptions) starts cold every time — a fresh call performs a full build regardless of any plugin cache hooks. So unless your pipeline runs a long-lived watcher (unusual for CI/build-on-deploy), you are effectively already doing full builds, and the entire cache-audit question is moot.

Recommended cutover procedure

1. Pin the lockfile and confirm identical resolved versions on both servers (npm ls or equivalent).
2. Align build-time environment variables between environments.
3. Build the same commit on both servers with a cold, one-shot build.
4. Byte-compare the output directories or diff content hashes of emitted files. Matching hashes are your go/no-go signal.
5. Cut over via your deployment mechanism (atomic symlink swap, load balancer, etc.) — zero downtime is a deployment concern, not something Rollup's cache provides.

For a small app, a full rebuild is typically seconds to low tens of seconds, so the cost of abandoning incremental builds during the migration window is negligible against the audit and staleness risk of trusting plugin cache behavior you cannot inspect.

One caveat: cache internals are version-sensitive. The behavior described reflects the Rollup 2.x–4.x line; confirm against your installed major version if it falls outside that range.