`cleanCode` stripped every `@nativescript/core/globals` import from served
modules. That is right for the main realm, where the entry installs the
globals once, and fatal for a worker realm: the worker script is that
isolate's only entry and the import is its only source of `setTimeout`,
`setInterval` and the other runtime globals. Worker-realm serves keep the
import, and a worker entry that does not carry one gets it added — the
production worker build bundles the module in, so the two paths agree.

Flavors were wired by name inside the package, so a framework could only
get device HMR by landing a PR here. `registerFrameworkFlavor({ flavor,
server, client })` from `@nativescript/vite/framework` registers a server
strategy and the specifier of a client strategy module shipped in the
framework's own package; `@nativescript/vite/hmr/client/framework.js` is
the device-side surface that module is written against.

The dev server looks registered strategies up next to the built-ins, seeds
the device bundle with the client module's `/ns/m/node_modules/<pkg>/…`
path (`__NS_CLIENT_STRATEGY_URL__`), and classifies the client package as
dev tooling — served per-module, never vendor-bundled or plugin-wrapped —
so its relative imports and its imports of the shared client resolve to the
running client's canonical URLs. `nativescript-vite init` and flavor
detection read a `nativescript.vite` declaration from the framework
package's package.json.

docs/framework-flavors.md is the walkthrough; @nativescript/vite-octane
(NativeScript/octane) is the worked example.

Vite's stock client never connects under device HMR, so its `page reload
<file>` / `hmr update <file>` lines describe a client that does not exist —
and `page reload` misleads while the device applies the same save in place
through a framework strategy.