feat(core): support opt-in Node lazy compilation

[ScriptedAlchemy]

Motivation

Node targets currently ignore dev.lazyCompilation. Frameworks that retain a Node runtime need to compile an optional server module when its dynamic import is requested, then resume that request without re-evaluating the entry.

Related to React Router plugin #155. Framework integration is tracked in plugin #158.

Changes

• Add dev.lazyCompilation.node to opt Node targets into lazy imports during development. Keep entries eager and require HMR; reject production and none modes.
• Enable Node HMR for the dev action and derive the activation URL from the dev server. Support explicit HTTP(S) URLs with a <port> placeholder.
• Document the runtime contract in English and Chinese: the framework retains the runtime, applies hot updates after successful compilation, and defines dependency acceptance boundaries.
• Cover native CommonJS and ESM runtimes through HTTP requests, including deferred compilation, accepted dependency edits, single module evaluation, and isolation between test runtimes. Assertions tolerate duplicate filesystem rebuild notifications while keeping runtime results and accepted-update counts exact.

Upstream dependency

Temporarily pin @rspack/core to npm:@rspack-canary/core@2.2.9-canary-a9cfd15e-20261009001219. It includes the lazy/HMR dependency-identity fix needed to resume imports in a retained runtime, plus the rebuild-origin support from Rspack #15968.

Before stable release: replace the canary pin and its loader-path snapshots with a released Rspack version containing the required fix.

Validation

At 02cc90587c13864bfd20c0e6e4f0191f1820e300:

• pnpm build and pnpm check passed.
• All 449 unit tests and 1,123 end-to-end tests passed locally.
• Ten consecutive focused Node runtime runs passed.
• Windows and Ubuntu e2e, Windows and macOS unit tests, and lint passed in CI.

Open questions

The tests establish retained-runtime behavior for the covered CJS/ESM scenarios. They do not establish universal restart-free Node support or a net startup/first-request performance benefit. Edits outside an application's acceptance boundaries still require framework handling.

Whether to keep the separate node option or align the configuration directly with Rspack remains a maintainer decision. See the review follow-up for the cross-project evidence and remaining coverage limits.

[cloudflare-workers-and-pages]

Deploying rsbuild with    Cloudflare Pages

Latest commit:	465c960
Status:	✅  Deploy successful!
Preview URL:	https://4eb5c41f.rsbuild-v2.pages.dev
Branch Preview URL:	https://codex-node-lazy-compilation.rsbuild-v2.pages.dev

View logs

[chenjiahan]

I'm not sure whether lazy compilation for Node targets currently works reliably in all supported scenarios. If we can confirm that it does, I'd prefer to keep the configuration aligned with Rspack and avoid introducing a separate node option.

@stormslowly cc

[stormslowly]

Lazy compilation makes the SSR server startup quickly, but it may introduce some APP restarts (like a full page reload in the web target).

Maybe we need to evaluate whether the quick startup benefits cover the effects of restarts.

[ScriptedAlchemy]

I haven't seen server restarts or other tabs reloading during lazy imports in the cases I tested. I also ran the startup comparison: lazy compilation was slower in all 40 paired runs on the example workload, with identical packages. I didn't find a performance benefit, so I'm closing this PR.

Measurements and reproduction steps.