feat: ESM resolver hardening, HTTP module loader, ns:module dev surface - #383
feat: ESM resolver hardening, HTTP module loader, ns:module dev surface#383NathanWalker wants to merge 7 commits into
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThis PR updates the runtime’s HTTP module loading and HMR dev-session plumbing, adds per-isolate module registry handling, and hardens the CI test harness. It also expands tests for HTTP ESM loading, import maps, blob modules, and remote module security. ChangesRuntime: HMR & HTTP module system
CI, test harness & test coverage
Estimated code review effort: 5 (Critical) | ~120 minutes Sequence Diagram(s)sequenceDiagram
participant Runtime
participant HMRSupport
participant ModuleInternal
participant Worker
Runtime->>HMRSupport: InitializeHmrDevGlobals(isolate, context, isWorker)
HMRSupport->>HMRSupport: kickstartPrefetch, setDevBootComplete
Runtime->>ModuleInternal: RunModule(path, outErrorMessage)
ModuleInternal->>ModuleInternal: LoadHttpModuleForUrl / LoadESModule
ModuleInternal-->>Runtime: bool + optional error
Runtime->>HMRSupport: CleanupHMRGlobals (main isolate only)
Runtime->>Worker: __NS_DEV__.terminateAllWorkers
Possibly related issues
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
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. Comment |
8310eac to
2c5d877
Compare
6dfbacd to
f7cdfcc
Compare
|
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:
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. There is likely a few that could move to JS if we want a smaller surface like __nsApplyStyleUpdate (just Application.addCss + restyle) and __nsGetLoadedModuleUrls (introspection) and others. Lmk if you see the boundary differently and we can make further adjustments. |
d24c897 to
4289539
Compare
There was a problem hiding this comment.
Actionable comments posted: 8
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
NativeScript/runtime/Runtime.mm (1)
445-458: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winHonor the new
RunModulefailure contract in main startup.Line 450 still discards the boolean result. Since
ModuleInternal::RunModulenow reports some failures by returningfalsewithout throwing, startup can continue after the main module failed.Proposed fix
void Runtime::RunMainScript() { Isolate* isolate = this->GetIsolate(); v8::Locker locker(isolate); Isolate::Scope isolate_scope(isolate); HandleScope handle_scope(isolate); - this->moduleInternal_->RunModule(isolate, "./"); + std::string err; + if (!this->moduleInternal_->RunModule(isolate, "./", &err)) { + throw NativeScriptException( + isolate, + err.empty() ? "Failed to run main module" : err, + "Error"); + } }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@NativeScript/runtime/Runtime.mm` around lines 445 - 458, Runtime::RunMainScript currently ignores the boolean result from ModuleInternal::RunModule, so startup can continue even when main module loading fails without throwing. Update RunMainScript to use the same failure contract as Runtime::RunModule by capturing the return value from moduleInternal_->RunModule and handling a false result as a startup failure, using the existing Runtime and ModuleInternal::RunModule symbols to locate the change.
🧹 Nitpick comments (4)
NativeScript/runtime/ModuleInternalCallbacks.h (1)
44-45: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick winKeep loaded-module introspection isolate-explicit.
Now that the registry is keyed by
v8::Isolate*,GetLoadedModuleUrls()should take the target isolate like the other registry APIs. Relying on an implicit current isolate makes worker/main diagnostics easier to mix up.Suggested API adjustment
-std::vector<std::string> GetLoadedModuleUrls(); +std::vector<std::string> GetLoadedModuleUrls(v8::Isolate* isolate);🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@NativeScript/runtime/ModuleInternalCallbacks.h` around lines 44 - 45, GetLoadedModuleUrls() is still using an implicit current isolate, which can mix up worker and main-thread diagnostics now that the module registry is isolate-keyed. Update the ModuleInternalCallbacks API so GetLoadedModuleUrls takes a v8::Isolate* parameter, and propagate that isolate through the implementation and any call sites to match the other registry helpers. Use the existing registry symbols in ModuleInternalCallbacks to keep the diagnostics explicitly scoped to the target isolate..github/workflows/npm_release.yml (1)
263-279: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick winBound the failure diagnostics payload.
Copying the full CoreSimulator log tree plus an unrestricted
log collectcan make failed CI runs slow or produce oversized artifacts. Prefer a targeted logarchive window and avoid uploading the whole CoreSimulator directory.Suggested tightening
# Simulator app crashes land in the host's DiagnosticReports. cp -R ~/Library/Logs/DiagnosticReports/. "$DIAG/DiagnosticReports/" 2>/dev/null || true - cp -R ~/Library/Logs/CoreSimulator/. "$DIAG/CoreSimulator/" 2>/dev/null || true + # Avoid uploading the full CoreSimulator log tree; the targeted + # logarchive below contains the simulator logs needed for this run. @@ - xcrun simctl spawn "$UDID" log collect --output "$DIAG/simulator.logarchive" 2>/dev/null || true + xcrun simctl spawn "$UDID" log collect --last 45m --output "$DIAG/simulator.logarchive" 2>/dev/null || truePlease verify the
log collect --lastoption on the macOS 15/Xcode 26 runner image.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/npm_release.yml around lines 263 - 279, The failure diagnostics step is too broad: it copies the entire CoreSimulator log tree and runs an unbounded log collect, which can create oversized artifacts and slow CI. In the diagnostics block that uses DIAG, xcrun simctl spawn, and log collect, stop archiving the full CoreSimulator directory and switch to a targeted unified-log collection window using the macOS 15/Xcode 26-supported log collect --last option so only recent logs are captured.NativeScript/runtime/Runtime.mm (1)
252-253: 🩺 Stability & Availability | 🔵 TrivialTrack the worker queue race TODO.
This TODO names a possible worker queue leak during termination ordering. Please track it before merge or file a follow-up so it does not get lost. I can help draft the issue or a fix plan.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@NativeScript/runtime/Runtime.mm` around lines 252 - 253, The TODO in Runtime.mm about a possible worker queue leak/race during termination ordering needs to be tracked before merge. Follow up on the worker lifecycle path in the Runtime-related initialization/termination flow, especially around the queue handling and the Terminate-before-Initialize scenario, and either replace the TODO with a concrete fix or create a tracked issue/fix plan linked to the worker queue race so it is not lost.NativeScript/runtime/URLImpl.cpp (1)
59-90: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winKeep
searchParamssynchronized afterurl.searchchanges.The getter returns the cached
_searchParamsforever. If code readsurl.searchParams, then later assignsurl.search, subsequenturl.searchParamsreads still expose the old query.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@NativeScript/runtime/URLImpl.cpp` around lines 59 - 90, The URLImpl::searchParams getter caches a single _searchParams instance and never refreshes it when url.search changes, so later reads can return stale query data. Update the URL.prototype.searchParams handling in URLImpl.cpp so the cached URLSearchParams is invalidated or resynced whenever the search setter runs, and make sure the getter recreates/updates the instance from the current search string before returning it.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@NativeScript/runtime/DevFlags.mm`:
- Around line 95-103: The allowlist check in RemoteUrlMatchesAllowlistEntry is
matching raw URL prefixes too early, which lets path-scoped entries be bypassed
with dot-segment paths. Update the matching logic to canonicalize or normalize
the URL path before applying the prefix/boundary rules, or explicitly reject
plain/encoded dot segments in DevFlags.mm so a trailing-slash allowlist entry
cannot match escaped paths.
In `@NativeScript/runtime/ModuleInternal.mm`:
- Around line 236-264: The debug handling in ModuleInternal.mm is swallowing
non-HTTP ES module failures by returning true or an empty namespace, which
prevents worker error propagation for .mjs loads. Update the
NativeScriptException catch and the moduleNamespace.IsEmpty path so debug mode
still surfaces failures to the caller for worker-loaded ESM, instead of always
pretending success; keep the existing HTTP debug logging, but ensure the
Worker.mm TryCatch can observe the error for the ES module load path.
In `@NativeScript/runtime/URLImpl.cpp`:
- Around line 94-100: The install script execution in URLImpl should not fail
silently: the current Compile/Run flow can leave blob URL support partially
initialized and a pending V8 exception uncleared. Update the script path in
URLImpl to wrap the v8::Script::Compile and script->Run calls in a v8::TryCatch,
then explicitly handle both compile and runtime failures by logging the error
and propagating it (or throwing) instead of ignoring the result. Use the
existing blob_methods script setup in URLImpl as the place to add this error
handling.
In `@NativeScript/runtime/Worker.mm`:
- Around line 486-499: The HMR termination loop in Worker::TerminateWorkers
currently iterates all entries from Caches::Workers, which can affect workers
from other runtimes. Update this callback to filter worker wrappers by the
current main isolate, matching the existing Runtime::~Runtime() behavior via
WorkerWrapper::GetMainIsolate(). Keep the existing running/closing checks and
only call WorkerWrapper::Terminate() for workers belonging to the same isolate.
In `@TestRunner/app/tests/esm/hmr/hot-data-ext.js`:
- Around line 51-73: The hot-data fixture is mutating shared HMR state by
invoking hot.accept, hot.dispose, hot.decline, and hot.invalidate in the shared
test helper, which makes later specs order-dependent. Update hot-data-ext.js so
the shared fixture only checks for the presence of HMR APIs and data on hot, and
remove lifecycle/callback registration from this path. If coverage for those
methods is needed, move it into a separate throwaway module or dedicated test
helper that is not reused across specs.
In `@TestRunner/app/tests/NodeBuiltinsAndOptionalModulesTests.mjs`:
- Around line 55-78: The test cleanup in the __ns_test_vendor__ import-map spec
is not restoring the runtime’s prior import-map state, which can leak
configuration into later specs. Snapshot the existing import-map before calling
configureRuntime in this test, then in the finally block restore that original
import-map instead of resetting to an empty imports object. Keep the existing
__nsVendorRegistry restore logic intact so the test remains hermetic.
In `@TestRunnerTests/Embassy/TCPSocket.swift`:
- Around line 60-66: The SO_NOSIGPIPE setup in TCPSocket is currently ignoring
the result of setsockopt, which can leave the socket in a state where send may
trigger SIGPIPE before Transport.handleWrite() can observe EPIPE. Update the
socket setup path in the TCPSocket initializer/helper to check the setsockopt
return value, and if it fails on Darwin, immediately treat it as a socket error
by closing the socket and propagating an error back to the caller instead of
discarding it. Use the TCPSocket and Transport.handleWrite symbols to locate the
write-path setup and keep the failure handling aligned with the existing socket
lifecycle.
In `@TestRunnerTests/TestRunnerTests.swift`:
- Line 24: The test setup in DefaultHTTPServer is still binding the server to
127.0.0.1 even though TCPSocket.bind(interface:) currently treats the interface
as IPv6, so the listener is not truly IPv4. Update the TestRunnerTests/server
setup to use the matching loopback family consistently (for example, switch both
server and client-side expectations to ::1/[::1]), or if IPv4 is required,
adjust TCPSocket and the DefaultHTTPServer path to support AF_INET first. Use
the existing DefaultHTTPServer initializer and TCPSocket.bind interface handling
to locate the change.
---
Outside diff comments:
In `@NativeScript/runtime/Runtime.mm`:
- Around line 445-458: Runtime::RunMainScript currently ignores the boolean
result from ModuleInternal::RunModule, so startup can continue even when main
module loading fails without throwing. Update RunMainScript to use the same
failure contract as Runtime::RunModule by capturing the return value from
moduleInternal_->RunModule and handling a false result as a startup failure,
using the existing Runtime and ModuleInternal::RunModule symbols to locate the
change.
---
Nitpick comments:
In @.github/workflows/npm_release.yml:
- Around line 263-279: The failure diagnostics step is too broad: it copies the
entire CoreSimulator log tree and runs an unbounded log collect, which can
create oversized artifacts and slow CI. In the diagnostics block that uses DIAG,
xcrun simctl spawn, and log collect, stop archiving the full CoreSimulator
directory and switch to a targeted unified-log collection window using the macOS
15/Xcode 26-supported log collect --last option so only recent logs are
captured.
In `@NativeScript/runtime/ModuleInternalCallbacks.h`:
- Around line 44-45: GetLoadedModuleUrls() is still using an implicit current
isolate, which can mix up worker and main-thread diagnostics now that the module
registry is isolate-keyed. Update the ModuleInternalCallbacks API so
GetLoadedModuleUrls takes a v8::Isolate* parameter, and propagate that isolate
through the implementation and any call sites to match the other registry
helpers. Use the existing registry symbols in ModuleInternalCallbacks to keep
the diagnostics explicitly scoped to the target isolate.
In `@NativeScript/runtime/Runtime.mm`:
- Around line 252-253: The TODO in Runtime.mm about a possible worker queue
leak/race during termination ordering needs to be tracked before merge. Follow
up on the worker lifecycle path in the Runtime-related
initialization/termination flow, especially around the queue handling and the
Terminate-before-Initialize scenario, and either replace the TODO with a
concrete fix or create a tracked issue/fix plan linked to the worker queue race
so it is not lost.
In `@NativeScript/runtime/URLImpl.cpp`:
- Around line 59-90: The URLImpl::searchParams getter caches a single
_searchParams instance and never refreshes it when url.search changes, so later
reads can return stale query data. Update the URL.prototype.searchParams
handling in URLImpl.cpp so the cached URLSearchParams is invalidated or resynced
whenever the search setter runs, and make sure the getter recreates/updates the
instance from the current search string before returning it.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 5096dcca-ed10-47ea-be7c-64aafa7275ac
📒 Files selected for processing (28)
.github/scripts/sample-hung-app.sh.github/workflows/npm_release.ymlNativeScript/runtime/DevFlags.hNativeScript/runtime/DevFlags.mmNativeScript/runtime/HMRSupport.hNativeScript/runtime/HMRSupport.mmNativeScript/runtime/ModuleInternal.hNativeScript/runtime/ModuleInternal.mmNativeScript/runtime/ModuleInternalCallbacks.hNativeScript/runtime/ModuleInternalCallbacks.mmNativeScript/runtime/Runtime.hNativeScript/runtime/Runtime.mmNativeScript/runtime/URLImpl.cppNativeScript/runtime/URLImpl.hNativeScript/runtime/Worker.hNativeScript/runtime/Worker.mmTestRunner/app/Infrastructure/Jasmine/jasmine-2.0.1/boot.jsTestRunner/app/tests/HttpEsmLoaderTests.jsTestRunner/app/tests/MethodCallsTests.jsTestRunner/app/tests/NodeBuiltinsAndOptionalModulesTests.mjsTestRunner/app/tests/RemoteModuleSecurityTests.jsTestRunner/app/tests/esm/hmr/hot-data-ext.jsTestRunner/app/tests/esm/hmr/hot-data-ext.mjsTestRunnerTests/Embassy/DefaultHTTPServer.swiftTestRunnerTests/Embassy/TCPSocket.swiftTestRunnerTests/Embassy/Transport.swiftTestRunnerTests/QUARANTINED_TESTS.mdTestRunnerTests/TestRunnerTests.swift
ada922f to
c81143d
Compare
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
NativeScript/runtime/Worker.mm (1)
228-229: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winHandle
RunModule’s new failure return in workers.
Runtime::RunModulenow reports load/evaluation failures viafalseplusoutErrorMessage. This worker path still ignores the return value and only checksTryCatch, so non-thrown HTTP ESM/TLA failures may never reachworker.onerror.Proposed fix
- runtime->RunModule(resolvedPath); + std::string errorMessage; + bool didRun = runtime->RunModule(resolvedPath, &errorMessage); + if (!didRun && !tc.HasCaught()) { + worker->PassUncaughtExceptionFromWorkerToMain( + errorMessage.empty() ? "Worker script failed: " + resolvedPath : errorMessage, + resolvedPath, "", 1, true); + worker->Terminate(); + return isolate; + }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@NativeScript/runtime/Worker.mm` around lines 228 - 229, The worker module loading path in Worker::Start still ignores Runtime::RunModule’s new false return, so failures that only populate outErrorMessage never surface to worker.onerror. Update the RunModule call site to capture the boolean result and error message, then route that failure through the same worker error handling path used for TryCatch so both thrown and non-thrown evaluation/load errors are reported consistently.
🧹 Nitpick comments (4)
TestRunner/app/tests/HttpEsmLoaderTests.js (2)
245-249: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueDead code after
pending()calls.
pending()called synchronously in a spec body throws internally and halts execution immediately, so the followingdone(); return;lines never run. Harmless but misleading; can be dropped for clarity.♻️ Simplify skip guards
if (!origin) { pending("REPORT_BASEURL not set; skipping host HTTP tests"); - done(); - return; }Also applies to: 271-275, 298-302, 323-327
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@TestRunner/app/tests/HttpEsmLoaderTests.js` around lines 245 - 249, The skip guards in the HTTP ESM loader specs contain dead code after synchronous pending() calls. In the relevant test blocks within HttpEsmLoaderTests.js, remove the unnecessary done(); return; lines that follow pending() so the guard reads cleanly and matches the actual control flow; apply the same simplification to the other pending() skip checks in the same test file.
242-344: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueRepeated skip-guard boilerplate across canonicalization tests.
The
if (!origin) { pending(...); done(); return; }block is duplicated across all four tests in this suite. Consider extracting a small helper (e.g.requireHostOriginOrSkip(done)) alongside the existingformatError/withTimeout/getHostOriginhelpers.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@TestRunner/app/tests/HttpEsmLoaderTests.js` around lines 242 - 344, The URL key canonicalization tests repeat the same host-skip guard in each case, making the suite noisy and harder to maintain. Add a small shared helper near the existing getHostOrigin, withTimeout, and formatError utilities (for example, a function like requireHostOriginOrSkip(done)) that checks for a missing origin, calls pending with the same message, then finishes the test early. Update each of the four describe("URL Key Canonicalization") specs to use that helper instead of duplicating the if (!origin) block.NativeScript/runtime/HMRSupport.mm (1)
8-18: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winInclude
<memory>directly forstd::shared_ptrandstd::make_shared.This file uses
std::shared_ptrandstd::make_sharedlater, but the changed include list does not include<memory>, so it relies on transitive includes.Proposed fix
`#include` <mutex> +#include <memory> `#include` "Helpers.h"🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@NativeScript/runtime/HMRSupport.mm` around lines 8 - 18, Add the missing direct include for <memory> in HMRSupport.mm because the file uses std::shared_ptr and std::make_shared and should not rely on transitive headers. Update the include block near the top of the file so the needed standard library types are declared explicitly, keeping the existing RuntimeConfig, Worker, and helper includes unchanged..github/workflows/npm_release.yml (1)
262-279: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winUDID fallback may resolve to the wrong simulator on a multi-runtime runner.
If no device is currently booted, the fallback searches
xcrun simctl list devices 'iPhone 16 Pro'across every installed runtime and takeshead -1. On a runner image with multiple Xcode/runtime versions pre-installed, this can match a same-named simulator from an unrelated iOS runtime that never ran the tests, producing an essentially empty/irrelevantsimulator.logarchiveinstead of the one from the actual failing run — undermining the stated goal of showing "the app's console output ... before a hang" (Line 262-263 comment).♻️ Possible mitigation
Filter the fallback list by the runtime actually used for testing (e.g. match the
OS=latestruntime forenv.XCODE_VERSION), or persist the UDID resolved byxcodebuild -destinationduring the "Xcode Tests" step to a file and reuse it here instead of re-searching by name only.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/npm_release.yml around lines 262 - 279, The UDID lookup in the simulator log collection step can pick the wrong device on runners with multiple runtimes because it falls back to a name-only search in xcrun simctl list devices. Update the logarchive collection logic to reuse the exact simulator used by the Xcode Tests step or filter the fallback by the same runtime/destination as the test run, then keep using that resolved UDID in the xcrun simctl spawn log collect path.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@NativeScript/runtime/HMRSupport.mm`:
- Around line 806-814: Timed-out prefetch work in HMRSupport.mm can still
complete later and overwrite g_prefetchCache with stale data after
dispatch_group_wait has already returned. Add a per-prefetch generation or
cancel marker around the prefetch flow in the relevant HMRSupport functions
handling the cache write path, and check that marker immediately before storing
the fetched body. Make sure the guard is shared by the scheduled blocks in both
affected sections so only the active reload cycle can commit into
g_prefetchCache.
- Around line 36-43: `InitializeHmrDevGlobals` only defines the `globalThis`
mirror once, so repeated or re-entrant installs can leave
`globalThis.__NS_DEV__` pointing at a stale object. Update the generated
assignment in `HMRSupport.mm` so the mirror is refreshed on each install instead
of only when undefined, while still preserving the `Object.defineProperty`
behavior used for `name` and the `__NS_DEV__` global.
In `@NativeScript/runtime/Runtime.mm`:
- Around line 137-148: Update the hasUrlScheme handling in Runtime::dirname
logic so single-segment HTTP-style module URLs like http://host/main.js are
reduced to the host root for import.meta.dirname instead of keeping the full
module URL. The current lastSlash > pathStart check in the modulePath branch is
too strict; adjust the condition or split logic so the final path segment is
stripped whenever a URL path exists after the host, while still preserving the
identity for host-only or non-hierarchical schemes such as node:fs and blob:abc.
In `@NativeScript/runtime/URLImpl.cpp`:
- Around line 61-89: The cached URLSearchParams instance in URLImpl is not
refreshed when the search string is reassigned, so stale values can be returned
after setting URL.search. Update the SetSearch logic in URLImpl to either clear
_searchParams when search changes or synchronize the existing object with the
new query string, so later URL.searchParams access reflects the latest value.
- Around line 26-91: The injected blob URL setup in URLImpl.cpp is not
idempotent: repeated execution can redeclare BLOB_STORE and InternalAccessor and
can fail when redefining URL.prototype.searchParams. Update the blob_methods
script so its top-level declarations are guarded or reused on subsequent
installs, and make the searchParams property definition configurable so the
accessor can be safely reinstalled without throwing. Use the existing
URL.createObjectURL, URL.revokeObjectURL, InternalAccessor, and
Object.defineProperty(URL.prototype, 'searchParams', ...) sections as the fix
points.
---
Outside diff comments:
In `@NativeScript/runtime/Worker.mm`:
- Around line 228-229: The worker module loading path in Worker::Start still
ignores Runtime::RunModule’s new false return, so failures that only populate
outErrorMessage never surface to worker.onerror. Update the RunModule call site
to capture the boolean result and error message, then route that failure through
the same worker error handling path used for TryCatch so both thrown and
non-thrown evaluation/load errors are reported consistently.
---
Nitpick comments:
In @.github/workflows/npm_release.yml:
- Around line 262-279: The UDID lookup in the simulator log collection step can
pick the wrong device on runners with multiple runtimes because it falls back to
a name-only search in xcrun simctl list devices. Update the logarchive
collection logic to reuse the exact simulator used by the Xcode Tests step or
filter the fallback by the same runtime/destination as the test run, then keep
using that resolved UDID in the xcrun simctl spawn log collect path.
In `@NativeScript/runtime/HMRSupport.mm`:
- Around line 8-18: Add the missing direct include for <memory> in HMRSupport.mm
because the file uses std::shared_ptr and std::make_shared and should not rely
on transitive headers. Update the include block near the top of the file so the
needed standard library types are declared explicitly, keeping the existing
RuntimeConfig, Worker, and helper includes unchanged.
In `@TestRunner/app/tests/HttpEsmLoaderTests.js`:
- Around line 245-249: The skip guards in the HTTP ESM loader specs contain dead
code after synchronous pending() calls. In the relevant test blocks within
HttpEsmLoaderTests.js, remove the unnecessary done(); return; lines that follow
pending() so the guard reads cleanly and matches the actual control flow; apply
the same simplification to the other pending() skip checks in the same test
file.
- Around line 242-344: The URL key canonicalization tests repeat the same
host-skip guard in each case, making the suite noisy and harder to maintain. Add
a small shared helper near the existing getHostOrigin, withTimeout, and
formatError utilities (for example, a function like
requireHostOriginOrSkip(done)) that checks for a missing origin, calls pending
with the same message, then finishes the test early. Update each of the four
describe("URL Key Canonicalization") specs to use that helper instead of
duplicating the if (!origin) block.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: db3ffc7d-0cdb-488b-a6db-465fc500c772
📒 Files selected for processing (26)
.github/scripts/sample-hung-app.sh.github/workflows/npm_release.ymlNativeScript/runtime/DevFlags.hNativeScript/runtime/DevFlags.mmNativeScript/runtime/HMRSupport.hNativeScript/runtime/HMRSupport.mmNativeScript/runtime/ModuleInternal.hNativeScript/runtime/ModuleInternal.mmNativeScript/runtime/ModuleInternalCallbacks.hNativeScript/runtime/ModuleInternalCallbacks.mmNativeScript/runtime/Runtime.hNativeScript/runtime/Runtime.mmNativeScript/runtime/URLImpl.cppNativeScript/runtime/URLImpl.hNativeScript/runtime/Worker.hNativeScript/runtime/Worker.mmTestRunner/app/Infrastructure/Jasmine/jasmine-2.0.1/boot.jsTestRunner/app/tests/HttpEsmLoaderTests.jsTestRunner/app/tests/MethodCallsTests.jsTestRunner/app/tests/NodeBuiltinsAndOptionalModulesTests.mjsTestRunner/app/tests/RemoteModuleSecurityTests.jsTestRunnerTests/Embassy/DefaultHTTPServer.swiftTestRunnerTests/Embassy/TCPSocket.swiftTestRunnerTests/Embassy/Transport.swiftTestRunnerTests/QUARANTINED_TESTS.mdTestRunnerTests/TestRunnerTests.swift
✅ Files skipped from review due to trivial changes (1)
- TestRunnerTests/QUARANTINED_TESTS.md
🚧 Files skipped from review as they are similar to previous changes (15)
- NativeScript/runtime/ModuleInternal.h
- .github/scripts/sample-hung-app.sh
- NativeScript/runtime/URLImpl.h
- NativeScript/runtime/Worker.h
- TestRunner/app/tests/MethodCallsTests.js
- NativeScript/runtime/Runtime.h
- TestRunner/app/tests/NodeBuiltinsAndOptionalModulesTests.mjs
- TestRunnerTests/Embassy/TCPSocket.swift
- TestRunner/app/tests/RemoteModuleSecurityTests.js
- TestRunnerTests/Embassy/DefaultHTTPServer.swift
- NativeScript/runtime/ModuleInternalCallbacks.h
- TestRunnerTests/Embassy/Transport.swift
- TestRunner/app/Infrastructure/Jasmine/jasmine-2.0.1/boot.js
- TestRunnerTests/TestRunnerTests.swift
- NativeScript/runtime/ModuleInternal.mm
c81143d to
e48b2ca
Compare
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
NativeScript/runtime/ModuleInternal.mm (1)
1031-1040: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winPropagate HTTP loader failures instead of returning an empty namespace
LoadHttpModuleForUrlalready throws on fetch/compile errors, but this debug branch turns that intoLocal<Value>(), soRunModulefalls back to the generic empty-namespace message and drops the real cause. Throw here forisHttpModulesooutErrorMessagecarries the loader error.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@NativeScript/runtime/ModuleInternal.mm` around lines 1031 - 1040, The HTTP module load path in ModuleInternal.mm is swallowing the real loader failure in the isHttpModule branch by returning an empty Local<Value>() when LoadHttpModuleForUrl fails. Update the RunModule/module compilation flow so that, instead of returning empty in the RuntimeConfig.IsDebug branch, it propagates the exception from LoadHttpModuleForUrl (or throws a NativeScriptException with the loader error) and lets outErrorMessage capture that cause. Keep the existing logPhase("compile", "fail", "http-loader") but ensure the failure exits via an error path, not a fallback namespace return.
♻️ Duplicate comments (1)
NativeScript/runtime/ModuleInternal.mm (1)
234-256: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick winWorker
.mjsESM failures are still swallowed in debug.The CJS
require()path was updated to gate on!cache->isWorker(Line 300) and rethrows for workers (Lines 348-350), but the ESM branch here still gates only on!isHttpModule. For a.mjsworker entry, a load failure returnstrue(Line 240) or an empty namespace returnstrue(Line 256), soWorker.mm'sTryCatchnever observes the failure andworker.onerrornever fires. This is the same concern raised previously and marked addressed — the fix appears to have landed only on the CJS path.Proposed direction
- if (RuntimeConfig.IsDebug && !isHttpModule) { + if (RuntimeConfig.IsDebug && !isHttpModule && !cache->isWorker) { Log(@"***** JavaScript exception occurred - detailed stack trace follows *****"); ... return true; // avoid termination in debug } else { SetOutErrorMessage(outErrorMessage, ex.getMessage()); + if (cache->isWorker && /* pending V8 exception available */) { + // rethrow so Worker.mm TryCatch routes to worker.onerror + } return false; } @@ - if (RuntimeConfig.IsDebug && !isHttpModule) { + if (RuntimeConfig.IsDebug && !isHttpModule && !cache->isWorker) { Log(@"Debug mode - ES module returned empty namespace, but telling iOS it succeeded"); return true;🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@NativeScript/runtime/ModuleInternal.mm` around lines 234 - 256, The ESM worker load path in ModuleInternal.mm still swallows failures in debug because it only checks RuntimeConfig.IsDebug and !isHttpModule, so .mjs worker entry errors return true instead of propagating. Update the ES module handling around the load-failure and empty-namespace branches to also exclude worker contexts, using the same worker-aware gating already applied in the require()/cache path, so Worker.mm’s TryCatch can observe the exception and fire worker.onerror.
🧹 Nitpick comments (1)
.github/workflows/npm_release.yml (1)
171-176: 🎯 Functional Correctness | 🔵 Trivial | 💤 Low valueUpdate the runtime-suite note to match the actual pin.
XCODE_VERSIONis^15.0, so the Xcode 26/iOS 26 comment is stale and misleading.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/npm_release.yml around lines 171 - 176, The runtime-suite note is stale and does not match the pinned Xcode version. Update the comment near the workflow’s macOS runner and XCODE_VERSION pin to describe the actual Xcode 15 / iOS 15 runtime instead of Xcode 26 / iOS 26, keeping the note consistent with the deterministic pinning rationale in the same block.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@NativeScript/runtime/ModuleInternal.mm`:
- Around line 1031-1040: The HTTP module load path in ModuleInternal.mm is
swallowing the real loader failure in the isHttpModule branch by returning an
empty Local<Value>() when LoadHttpModuleForUrl fails. Update the
RunModule/module compilation flow so that, instead of returning empty in the
RuntimeConfig.IsDebug branch, it propagates the exception from
LoadHttpModuleForUrl (or throws a NativeScriptException with the loader error)
and lets outErrorMessage capture that cause. Keep the existing
logPhase("compile", "fail", "http-loader") but ensure the failure exits via an
error path, not a fallback namespace return.
---
Duplicate comments:
In `@NativeScript/runtime/ModuleInternal.mm`:
- Around line 234-256: The ESM worker load path in ModuleInternal.mm still
swallows failures in debug because it only checks RuntimeConfig.IsDebug and
!isHttpModule, so .mjs worker entry errors return true instead of propagating.
Update the ES module handling around the load-failure and empty-namespace
branches to also exclude worker contexts, using the same worker-aware gating
already applied in the require()/cache path, so Worker.mm’s TryCatch can observe
the exception and fire worker.onerror.
---
Nitpick comments:
In @.github/workflows/npm_release.yml:
- Around line 171-176: The runtime-suite note is stale and does not match the
pinned Xcode version. Update the comment near the workflow’s macOS runner and
XCODE_VERSION pin to describe the actual Xcode 15 / iOS 15 runtime instead of
Xcode 26 / iOS 26, keeping the note consistent with the deterministic pinning
rationale in the same block.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 72cb5ffd-ae59-44eb-b7be-58246e617135
📒 Files selected for processing (14)
.github/workflows/npm_release.ymlNativeScript/runtime/DevFlags.hNativeScript/runtime/DevFlags.mmNativeScript/runtime/HMRSupport.hNativeScript/runtime/HMRSupport.mmNativeScript/runtime/ModuleInternal.mmNativeScript/runtime/ModuleInternalCallbacks.mmNativeScript/runtime/Runtime.mmNativeScript/runtime/URLImpl.hNativeScript/runtime/Worker.hNativeScript/runtime/Worker.mmTestRunner/app/tests/HttpEsmLoaderTests.jsTestRunner/app/tests/NodeBuiltinsAndOptionalModulesTests.mjsTestRunnerTests/TestRunnerTests.swift
💤 Files with no reviewable changes (6)
- NativeScript/runtime/URLImpl.h
- NativeScript/runtime/DevFlags.h
- NativeScript/runtime/Worker.mm
- TestRunnerTests/TestRunnerTests.swift
- NativeScript/runtime/HMRSupport.mm
- NativeScript/runtime/DevFlags.mm
🚧 Files skipped from review as they are similar to previous changes (5)
- NativeScript/runtime/Worker.h
- TestRunner/app/tests/NodeBuiltinsAndOptionalModulesTests.mjs
- TestRunner/app/tests/HttpEsmLoaderTests.js
- NativeScript/runtime/HMRSupport.h
- NativeScript/runtime/Runtime.mm
27efd66 to
7fd30c1
Compare
7fd30c1 to
e4b9236
Compare
3cd6611 to
c14a5a6
Compare
4a95770 to
a189892
Compare
Canonicalize module identity into three registry shapes — http(s) URLs, custom schemes (node:, blob:, optional:), and absolute file paths — and key the module registries by v8::Isolate instead of thread_local storage. import() now rejects missing bare specifiers instead of installing placeholders; optional-module placeholders are built without string interpolation, detection is unified in IsLikelyOptionalModule, and module source preserves embedded NUL bytes. Thenables handed to the loader from JS are adopted properly. Blob URLs (blob:nativescript/<uuid>) become first-class module identities via URL.createObjectURL and URL.InternalAccessor. The prewarm/prefetch machinery is replaced by an async module-graph loader; boot hands off to a manual runloop that pumps pending module work when the entry script has not reached UIApplicationMain yet (e.g. a top-level-await entry still loading its graph). RunModule surfaces the failure cause to callers through an error out-parameter.
Dev sessions serve the app's module graph over HTTP during development,
with a mechanism-only dev-loader contract: policy stays in JS tooling,
the runtime supplies fetch/registry/invalidations. The loader is
deny-by-default — remote allowlist entries only authorize URLs on a
URL-component boundary ('/', '?', '#' or exact match), refusing
lookalike-host and lookalike-port bypasses; a specific port must be
listed explicitly. Hot-path hash containers use robin_hood maps.
Per-fetch URL logging is opt-in via the httpFetchUrlLog config flag
(volume is one line per fetch), alongside the existing
logScriptLoading-gated diagnostics.
The dev-loader control surface (HMRSupport) is reachable from JS as the ns:module builtin module: NsBuiltinModules routes ns:module through BuildNsModuleBinding — the binding builder decides build-dependent membership — and ns-module.js (compiled in via js2c) shapes and freezes whatever arrives. TypeScript declarations ship in types/ns-module.d.ts, and docs/ns-builtin-modules.md documents the surface.
Worker entry-script load failures now reach worker.onerror instead of failing silently. Messages posted before the worker's entry script has installed onmessage are no longer dropped: ConcurrentQueue::Signal re-arms the drain source without enqueueing (a silent no-op when racing Terminate), and WorkerWrapper retries delivery through a deferred drain, with drainRetryPending_ preventing one stacked retry per attempt.
HttpEsmLoaderTests, RemoteModuleSecurityTests, and the node-builtins / optional-modules suites exercise the async loader, allowlist boundary matching, and the ns:module surface; the Jasmine boot shim awaits promise-returning specs so async failures fail the run. The Embassy test HTTP server is hardened for the loader suites, and QUARANTINED_TESTS.md records specs excluded from the run and why. On CI, the release workflow now collects crash reports (.ips) and the simulator's unified log when the runtime suite fails, since the xcresult captures nothing from inside the app.
b883978 to
ff19da9
Compare
Framework-agnostic hot module replacement on iOS with native ES modules: the device fetches modules over HTTP from the Vite dev server and applies hot updates without restarting the process.
The runtime's entire dev surface is one builtin module —
ns:module— resolved through the samens:registry asns:util(#418):require("ns:module"), staticimport, andimport()all yield the same frozen per-realm module, materialized lazily on first resolution. The dev surface defines no globals. Four primitives, each traceable to a V8-embedder or OS constraint:configureLoader(config)ResolveModuleCallback. The sole channel by which server/framework URL policy enters the runtime — native code carries no URL vocabulary of its owninvalidateModules(urls)v8::Modulerecords and arms a CFNetwork cache-bust noncegetLoadedModuleUrls()setDevBootComplete(bool)Debug builds also carry
canonicalizeHttpUrlKey(url), a pure test diagnostic. Missing members are simply absent — never present-but-throwing — so feature checks work.Async module-graph pipeline
HTTP module loads run a three-phase pipeline (
StartAsyncHttpModuleGraphLoad): bodies fetch concurrently onNSURLSessionbackground queues while the graph is discovered viaScriptCompiler::CompileModule+GetModuleRequests(); instantiation then runs with a lookup-only synchronousResolveModuleCallback; evaluation is promise-chained under top-level await. The runtime fetches exactly the requested graph — concurrent per-module fetches overlap the dev server's transform work with on-device compile. A synchronous fetch (HttpFetchText) remains as the resolver's fallback for URLs the walk did not cover. Boot pressure is answered at the source: the dev server pre-bundles@nativescript/coreand node_modules into single-eval payloads, and the pipeline fetches the remaining app graph concurrently.Module identity & freshness
Module identity is the canonical URL: the server emits exactly one URL per module and never varies it for freshness (this closes the realm-split /
Cannot redefine propertycrash class). Canonicalization survives only to absorb externally-caused variance (Vite's?v=/?import/?t=markers,file://http://wrapping); the mechanism (fragment strip, param drop, sort) is native, while the vocabulary (which params to strip, which path prefixes are dev endpoints, which paths keep their query verbatim) is supplied by the client viaconfigureLoader. Freshness is explicit eviction at both layers that could serve a stale byte: the V8 module registry, and a one-shot__ns_dev_noncethat defeats CFNetwork's cache (observed serving stale bodies on iOS 18+/26 Sim despiteno-storeand a zero-capacityNSURLCache).Additional
ModuleInternalCallbacks.mm): HTTP(S) URLs end-to-end (resolve, fetch, dynamic import) and.jsonimports compiled into synthetic ES modules. Builtin specifiers (ns:, registerednode:) resolve only through the registry — an import-map entry can never shadow them onto HTTP.v8::Isolate*(not thread-locals); worker teardown preserves the main isolate's process-wide dev state; worker entry-script errors propagate toworker.onerror.IsRemoteUrlAllowed()(DevFlags.mm): deny-by-default in release, opt-in viasecurity.allowRemoteModules(+ optionalremoteModuleAllowlist).TestRunner/app/tests/HttpEsmLoaderTests.js) pin thens:modulemodule shape, therequire/import()identity, and the canonical-key behavior.