Walkthrough

Adds relative dynamic import() resolution for file:// modules in the Android runtime. A new NormalizeDotSegments() path helper and ResolveFileRelative() function are added to ModuleInternalCallbacks.cpp, and ImportModuleDynamicallyCallback is updated to resolve relative specifiers to absolute file:// URLs before delegating to ResolveModuleCallback. Three new .mjs fixture files and matching Jasmine tests validate same-directory, parent-directory, and app-root relative import scenarios.

Changes

Relative Dynamic Import Resolution

Sequence Diagram(s)

sequenceDiagram
  participant V8 as V8 Engine
  participant IMDC as ImportModuleDynamicallyCallback
  participant RFR as ResolveFileRelative
  participant NDS as NormalizeDotSegments
  participant RMC as ResolveModuleCallback

  V8->>IMDC: dynamic import("./sibling.mjs", referrer=file:///app/esm-subdir/parent.mjs)
  IMDC->>RFR: ResolveFileRelative(referrer, "./sibling.mjs")
  RFR->>RFR: strip fragment/query → base dir = /app/esm-subdir/
  RFR->>NDS: NormalizeDotSegments("/app/esm-subdir/sibling.mjs")
  NDS-->>RFR: "/app/esm-subdir/sibling.mjs"
  RFR-->>IMDC: "file:///app/esm-subdir/sibling.mjs"
  IMDC->>RMC: ResolveModuleCallback("file:///app/esm-subdir/sibling.mjs", empty referrer)
  RMC-->>V8: resolved sibling module

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐇 A dot-dot here, a slash right there,
The path was tangled beyond repair!
Now NormalizeDotSegments leads the way,
ResolveFileRelative saves the day.
Siblings found from parent and child—
Relative imports, finally reconciled! 🌿

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

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.

• X
• Mastodon
• Reddit
• LinkedIn

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

@coderabbitai, the test-app pins Jasmine 2.0.1, which has no done.fail: the async callback is a plain function with no .fail property, so done.fail is undefined and .then(() => done(), done.fail) would pass an undefined rejection handler, leaving a rejection to surface as the timeout it is meant to avoid.

This version's expectations also do not throw on failure (addExpectationResult records the result, it does not throw and there is no throwOnExpectationFailure), so the explicit (err) => { expect(err).toBeUndefined(); done(); } handler always reaches done(). Keeping the current form.

@adrian-niculescu: Thanks for the detailed explanation — that's a clear constraint from the pinned Jasmine 2.0.1 version. The current form is correct given that done.fail is absent and expectations don't throw in that version. I'm withdrawing my earlier concern.

Learnt from: adrian-niculescu
URL: https://github.com/NativeScript/android/pull/1976

Timestamp: 2026-06-23T22:07:53.313Z
Learning: The NativeScript Android test-app (NativeScript/android) pins Jasmine 2.0.1. In this version: (1) `done` is a plain function with no `.fail` property, so `done.fail` is `undefined` — using `.then(() => done(), done.fail)` silently passes `undefined` as the rejection handler and unhandled rejections surface as spec timeouts instead of failures. (2) `addExpectationResult` records failures without throwing and there is no `throwOnExpectationFailure`, so an explicit rejection handler `(err) => { expect(err).toBeUndefined(); done(); }` always reaches `done()`. The correct async test pattern for this version is the explicit two-handler form rather than `done.fail`.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

@adrian-niculescu: Understood — the concern was already withdrawn and the Jasmine 2.0.1 constraints have been noted in the knowledge base. No further action needed here; the current test form is the right one for the pinned version.

Nice fix, ios may need similar @adrian-niculescu ?

@NathanWalker, thanks and thank you for the quick review! iOS already handles this. In ImportModuleDynamicallyCallback, vanilla iOS anchors a relative .//../ specifier on the referrer's resource URL (referrer->GetResourceName()), derives the base directory, joins, and collapses the dot-segments:

https://github.com/NativeScript/ios/blob/6778dfdd5b436be0dad51f1f64df1e1408d8e76c/NativeScript/runtime/ModuleInternalCallbacks.mm#L2363-L2401

then passes the resulting absolute path to ResolveModuleCallback, so a file:// referrer's relative specifier never falls back to the app root:

https://github.com/NativeScript/ios/blob/6778dfdd5b436be0dad51f1f64df1e1408d8e76c/NativeScript/runtime/ModuleInternalCallbacks.mm#L2411-L2413

This Android change brings the file:// path to parity. Static imports were already fine on both platforms.