[o-alexandrov]

Closes #10957.

Problem

HmrStage's module_table() / index_ecma_ast() accessors call ScanStageCache::get_snapshot(), which unwraps unconditionally (crates/rolldown/src/types/scan_stage_cache.rs:78). The snapshot only exists when experimental.incremental_build is on.

prepare_build_context already forces that flag whenever experimental.dev_mode is set (crates/rolldown/src/utils/prepare_build_context.rs:279), so Vite's bundledDev is unaffected. But dev() accepts input options with neither flag. The engine constructs and builds fine, then panics the worker thread on the first file change:

thread 'rolldown-worker' panicked at crates/rolldown/src/types/scan_stage_cache.rs:79:28:
called `Option::unwrap()` on a `None` value

thread 'rolldown-worker' panicked at futures-util/src/future/future/shared.rs:300:25:
inner future panicked during poll

error: inner future panicked during poll  code: "GenericFailure"

The panic poisons the shared future, so the engine is unusable afterwards. Same unwrap as #9728 / #9730, reached from a plain transform hook using addWatchFile.

Fix

A dev engine cannot function without the snapshot, so DevEngine::new enables incremental_build at construction instead of leaving the invalid configuration representable. This mirrors what prepare_build_context already does for dev_mode.

I also prototyped the alternative (an early has_snapshot() check in compute_hmr_update_for_file_changes returning HmrUpdate::FullReload, matching the existing guard in compile_lazy_entry at hmr_stage.rs:542). It works, but it is dead code once the option can no longer be off, so I dropped it to keep the diff minimal. Happy to switch if you prefer defence in depth there.

Note on [lib] test = false

crates/rolldown_dev/Cargo.toml had test = false under [lib], so unit tests in this crate were never compiled or run, including by just test-rust (cargo test --workspace --exclude rolldown_binding). The crate has no other tests, so this drops the setting rather than working around it. Restore that line if it was deliberate, and tell me where you would prefer the regression test to live.

Verification

• New unit test dev_engine_forces_incremental_build_on asserts the constructed bundler has incremental build enabled. cargo test -p rolldown_dev runs it and passes (1 passed).
• End to end through the JS API: built rolldown_binding with this change, swapped it into a vite@8.3.0 install, and ran a dev() script with a transform hook calling addWatchFile on a graph module, with no devMode and no incrementalBuild. Before: the scan_stage_cache panic above. After: no panic, and the engine emits a correct Patch carrying the re-transformed code.
• cargo test -p rolldown --test integration: 2006 passed, 5 failed. The same 5 fail identically on unmodified main in my environment (missing fixture node_modules for cjs_module_lexer_compat / util_deprecate, and the test262 submodule not cloned).
• cargo fmt and cargo clippy -p rolldown_dev --all-targets are clean.
• Not verified locally: the full just test-rust workspace suite and the Node test suites.

[codspeed]

Merging this PR will not alter performance

✅ 7 untouched benchmarks
⏩ 10 skipped benchmarks¹

---

_{Comparing o-alexandrov:fix/dev-engine-force-incremental-build (40ffc47) with main (5c676e5)}

Footnotes

1. 10 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[h-a-n-a]

Thanks!