[NathanWalker]

Summary

Extracts facebook::jsi and rnv8::V8Runtime into two standalone, opt-in packages so the core @nativescript/ios and @nativescript/android runtime binaries remain completely free of JSI bloat:

• @nativescript/ios-jsi (packages/ios-jsi):
  • Distributed as a Swift Package (Package.swift) wired via nativescript.config.ts (SPMPackages) with zero CocoaPods required.
  • Provides facebook::jsi and rnv8::V8Runtime for iOS.
  • Exposes NativeScriptJSIRuntime(), tns::GetJSIRuntime(), and Objective-C/Swift JSIRuntime.runtime() / JSIRuntime.runtimePointer() keyed per v8::Isolate::GetCurrent() (supporting both main thread and Worker isolates) without depending on internal NativeScript runtime headers.
• @nativescript/android-jsi (packages/android-jsi):
  • Provides facebook::jsi and rnv8::V8Runtime (libnativescript-jsi.so) for Android.
  • Resolves V8 symbols directly against the loaded libNativeScript.so runtime in the process and keys std::shared_ptr<facebook::jsi::Runtime> per v8::Isolate::GetCurrent().
  • Exposes NativeScriptJSIRuntime(), tns::GetJSIRuntime(), and org.nativescript.jsi.JSIRuntime JNI helpers.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. 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

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 6a872667-b903-4bdb-b740-43549176eb14

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

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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

[ammarahm-ed]

Hello Nathan, i like the enthusiasm here but I believe these should be in a separate repo, not part of the runtimes repo at all.

Runtimes are strictly just Nativescript runtimes and this jsi implementation has a very niche use here and shouldn't be added. Let's keep the runtimes clean and focused on what they are supposed to do. Provide Native APIs in JS.

Even if you still wanted, this should have landed in the v8 runtime repo because it's v8 only AFAIK which is something I am against too. Keep this in a separate repo outside v8 or the runtimes repo.

[NathanWalker]

Do you feel https://github.com/NativeScript/plugins or https://github.com/NativeScript/ui-kit is better place?
They do seem more runtime related like the react-native package itself no? @ammarahm-ed

[ammarahm-ed]

@NathanWalker This repo is the wrong home for it. jsi::Runtime is React Native's abstraction. This repo is the NativeScript runtimes.

If you want this to exist, put it in its own repo and depend on a published runtime version. Then you can move as fast as you like without the runtime holding you back, or the other way round.

[NathanWalker]

@ammarahm-ed JSI is already part of this repo (the Hermes backend in ffi/hermes/jsi, packages/react-native, and your nativescript::engine layer on android-react-native from #69). The main reason to keep these here is that V8Runtime has to match the runtime's exact V8 version, so keeping them next to the runtime means they ship in sync. In a separate repo we'd need a version matrix and CI just to stop them drifting apart.

Android is the exception for now, since main doesn't build an Android runtime yet and android-jsi links against the published @nativescript/android. That gets sorted once #69 lands.

I'll clean this up so it builds against the runtime's own V8 headers instead of shipping a copy, and pin it to a runtime version. Longer term I'd like it to work across engines so it isn't V8-only. Hermes is basically free since the runtime already holds a jsi::Runtime, and the rest could sit on top of your engine layer once it's on main. Wrote up how here: https://github.com/NativeScript/runtimes/blob/73bbeadeba16d5a5b4e72ae39134d3af7c7d5374/docs/jsi-multi-engine.md

Would that work for you?

[ammarahm-ed]

I still think this shouldn't live here.

JSI shows up in this repo only where something hands us a jsi::Runtime: Hermes is a JSI runtime, and React Native gives us its own. We use it. This PR is different. It builds a JSI runtime for V8 and offers it as a public API for outside libraries. That's a new commitment, and it's one this repo would have to keep working through every engine upgrade.

Keep this in its own repo, pinned to a published runtime version. If it needs something from the runtime, like a supported way to get the isolate, or the jsi::Runtime Hermes already has, open an issue for that hook and we'll add it properly. We can revisit multi-engine once the engine layer has landed and settled, and once we've decided we want this.

@DjDeveloperr can comment on this too but It's a hard no for me.

[NathanWalker]

Fair enough, @ammarahm-ed. Using a jsi::Runtime is different from providing one, and I agree a public V8 JSI implementation shouldn't become something this repo has to support. I'll move it to its own repo (probably on it's own NativeScript/jsi) and pin it to a published runtime version.

For that to work without drifting from V8, I'll open issues for a few small hooks later:

1. V8 headers and version in the runtime release. Ship the exact V8 headers (or a version string plus a headers artifact) with each published runtime, so the external package builds against what's actually running and doesn't vendor its own copy.
2. A supported way to get the isolate. A stable, documented way to get the current v8::Isolate and run on its thread, so the package doesn't depend on runtime internals.
3. Stable exported V8 symbols on Android. A defined set of symbols that libNativeScript.so promises to export, so resolving them isn't guesswork.
4. An accessor for the Hermes jsi::Runtime. Something like GetJSIRuntime() for the runtime Hermes already holds.

I'll close this PR once the new repo is up. Multi-engine can wait until the engine layer has landed and settled.