GeezerVison

With webpack, ns run windows syncs the hot-update files into bin\app, but nothing tells the running app to apply them, so the CLI restarts the app on every change. On Android and iOS the runtime calls global.__onLiveSync() after a LiveSync, and webpack's HMR runtime hooks that to run its hot update.

Changes

template/framework/__PROJECT_NAME__/RuntimeHost.cs (Debug builds only):

• WatchLiveSync(dispatcherQueue) watches the app's LocalState for an ns-livesync marker. When the marker appears or changes, the host consumes it on the UI thread and runs __onLiveSync() through runtime_runscript.
• While it watches, the host writes ns-livesync-ready. The CLI only signals an app whose host wrote it, so a newer CLI with an older host still restarts as before. The ready marker is deleted at startup and on dispose.

App.xaml.cs starts the watcher once the pump runs.

The CLI side is NativeScript/nativescript-cli (against feat/windows). It writes the marker after syncing, and now restarts on a full sync, which is how the CLI recovers from a hot update that fails.

Testing

End to end on Windows 11 (Debug, x64): a TypeScript app on webpack 5.99.7, core and @nativescript/webpack built from feat/windows, this template, a current nativescript.dll and the CLI branch:

• Editing app.css: the CLI synced the hot-update files and logged "Refreshing application" with no restart. The app logged [HMR] success | Successfully applied update. with the same PID.
• Editing app.ts (not hot-acceptable): the app logged [HMR] failure | A module has not been accepted., and the CLI then restarted the app (new PID), as on Android and iOS.

I haven't built the published @nativescript/windows-* packages from this template. The NativeScriptWindowsDemo and TestApp copies of the host are unchanged.