feat: HMR dev-sessions, ESM resolver hardening, dev-mode runtime globals

[NathanWalker]

Adds robust Hot Module Replacement plus the supporting ESM resolver hardening and dev-session globals that make hot reload viable on iOS.

• import.meta.hot: data, accept, dispose, prune, decline, invalidate, on/off/send event surface.
• Dev-session globals (__nsStartDevSession, __nsReloadDevApp, __nsInvalidateModules, __nsRunHmrDispose, __nsRunHmrPrune, __nsKickstartHmrPrefetch, __nsGetLoadedModuleUrls, __nsApplyStyleUpdate, __nsConfigureDevRuntime, __nsTerminateAllWorkers).
• Speculative HTTP module prefetch with canonical-key normalization so __ns_hmr__/v<N> and __ns_boot__/b<N> tag prefixes share hot.data identity across reload cycles.
• ESM resolver hardening in ModuleInternalCallbacks.mm to:
  • Handle HTTP/HTTPS module URLs end-to-end (resolution, fetch, canonical-key collapse, dynamic import).
  • Compile .json imports into synthetic ES modules.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 62f4d6a9-e9a4-46d5-acf6-23f726f070d3

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[NathanWalker]

Blob can likely be split into separate PR. Not directly attributable to this pull request (at a time, I used blob urls with hmr updates but found standard http networking of es modules to suffice fine) - but useful on it's own.

[edusperoni]

I'm not sure I understand the goal of these "dev sessions"? What do these need specifically from the runtime that's not an "user land" thing?

[NathanWalker]

I'm not sure I understand the goal of these "dev sessions"? What do these need specifically from the runtime that's not an "user land" thing?

Yeah good question @edusperoni, the "dev session" naming here probably over (or mis) characterizes things.

The "session" part is just the contract for booting from a dev server over HTTP instead of the on-disk bundle. It does three things a one-shot bundle loader doesnt: point resolution at an HTTP origin + install the import map before the first import, give a re-entrant boot (import client > import entry) that can re-run for a full reload without relaunching the process, and bubble import failures back as a rejected promise so the client can show an overlay instead of the app just dying.

Could it be userland? I think the thing that trips people up (tripped me up too) is that on the web HMR is userland because the browser is the runtime; it already ships a spec ESM loader that fetches over HTTP and a host-owned module map you poke at by varying the URL. Vite's client gets to be "just JS" because it sits on top of that. Here V8 is embedded by us, and bare V8 ships no loader at all; every piece of it is an embedder host callback only native can install. So the litmus test is pretty clean: anything that has to install/drive a V8 host callback or mutate V8's module map cant be userland, everything else stays in JS.

This may help expand a few things:

• The HTTP ESM loader, import 'http://...', is resolved inside ResolveModuleCallback / the dynamic-import callback, before any user code for that module even runs. And in V8 10.3.22 that static callback is synchronous, which is the whole reason the prefetch engine exists (issue with V8's sync walk from JS, and a serial network walk on the UI thread trips the launch watchdog; an iOS issue I sort of knew about long ago so was interesting to be reminded of here).
• Identity-preserving eviction (__nsInvalidateModules), the registry is host-owned (g_moduleRegistry) and theres no JS API to evict/re-instantiate a compiled record. This is the most NS-specific one: the web just mints a new identity per save with ?t=, but we cant, because module identity is load-bearing for native interop - mint a fresh realm for a @nativescript/core module and the native patches collide leading to Cannot redefine property. So the runtime has to own eviction that collapses back to one canonical identity.
• import.meta.hot: import.meta only gets populated in SetHostInitializeImportMetaObjectCallback, and hot.data only survives a swap if it's keyed to the runtime's canonical module key, which userland doesnt have.
• Reboot teardown: terminating native-owned workers + ordered v8::Global/thread-local cleanup before isolate disposal.
  Everything protocol-ish I deliberately left in JS: the WebSocket, the wire format, evictPaths/closure computation, accept/dispose policy; all in @nativescript/vite's client. Runtime exposes mechanism, client owns policy; nothing links or version-pins vite, and unknown URLs just fall through to a generic HTTP loader.

So really these globals arent "a dev-session feature" so much as the embedder half of a spec ESM loader + an identity-preserving module map. The part the browser hands Vite for free. The two that could move to JS if we want a smaller surface are __nsApplyStyleUpdate (just Application.addCss + restyle) and __nsGetLoadedModuleUrls (introspection). Lmk if you see the boundary differently.