@nativescript/vite: dev deps-bundle eagerly vendors the full octane DOM graph #11440

Context

Running an Octane (@nativescript-community/octane) app in dev on iOS. The deps-bundle (/ns/deps-bundle.mjs, node_modules/.ns-vite/deps-bundle-ios-*.mjs) contains 86 modules including the entire DOM-side octane runtime: octane/dist/runtime.js, dom-bindings.js, dom-stage.js, dom-tables.js, dom-binding-*, hydration/*, server-rpc-*, devalue, css.js.

Why it happens

The bundle's entry set is the union of the vendor collection (package.json dep roots) + the persisted boot closure. octane is a dep root, so octane/dist/index.js gets vendored wholesale — and its import graph pulls the DOM modules. Nothing in the app actually uses them: compiled components reference @nativescript-community/octane, which only imports octane/universal/native.

Impact

Dev-only (the production vendor.mjs has zero DOM modules — tree-shaking works correctly). But it's a meaningfully larger payload for every dev boot and a footgun for module-identity bugs: the vendored octane realm is a second copy of the runtime that any uncompiled import 'octane' resolves into.

Possible directions

• Let consumers mark dep roots as "resolve via exports subpath" or exclude from the vendor seed (e.g. octane → octane/universal/native).
• Or treat packages whose deep files are only reachable through another vendored dep as non-seedable.

Measured on @nativescript/vite 8.0.10, @nativescript-community/octane 0.2.0, octane 0.4.0.