feat: React Native support

[shirakaba]

About

This PR adds React Native support, following the react-native-node-api prebuilds standard, a format which is understood by both Node.js and React Native.

Change in structure

Following the prebuilds standard means adopting a new file structure.

packages/ios

- dist
- └── ios-universal
-     └── NativeScript.xcframework
-         ├── Info.plist
-         ├── ios-arm64
-         │   └── NativeScript.framework
-         │       ├── Headers
-         │       │   └── NativeScript.h
-         │       ├── Info.plist
-         │       ├── NativeScript
-         │       └── _CodeSignature
-         │           └── CodeResources
-         └── ios-arm64_x86_64-simulator
-             └── NativeScript.framework
-                 ├── Headers
-                 │   └── NativeScript.h
-                 ├── Info.plist
-                 ├── NativeScript
-                 └── _CodeSignature
-                     └── CodeResources
+ build
+ └── RelWithDebInfo
+     └── NativeScript.apple.node
+         ├── Info.plist
+         ├── ios-arm64
+         │   └── NativeScript.framework
+         │       ├── Headers
+         │       │   └── NativeScript.h
+         │       ├── Info.plist
+         │       ├── NativeScript
+         │       └── _CodeSignature
+         │           └── CodeResources
+         ├── ios-arm64_x86_64-simulator
+         │   └── NativeScript.framework
+         │       ├── Headers
+         │       │   └── NativeScript.h
+         │       ├── Info.plist
+         │       ├── NativeScript
+         │       └── _CodeSignature
+         │           └── CodeResources
+         └── react-native-node-api-module

packages/macos

- dist
- └── macos
-     └── NativeScript.node
+ build
+ └── RelWithDebInfo
+     └── NativeScript.apple.node
+         ├── Info.plist
+         ├── macos-arm64_x86_64
+         │   └── NativeScript.framework
+         │       ├── Headers -> Versions/Current/Headers
+         │       ├── NativeScript -> Versions/Current/NativeScript
+         │       ├── Resources -> Versions/Current/Resources
+         │       └── Versions
+         │           ├── 0.1.0
+         │           │   ├── Headers
+         │           │   │   └── NativeScript.h
+         │           │   ├── NativeScript
+         │           │   ├── Resources
+         │           │   │   └── Info.plist
+         │           │   └── _CodeSignature
+         │           │       └── CodeResources
+         │           └── Current -> 0.1.0
+         └── react-native-node-api-module

How to review

To make this PR easy to review, I have structured it as two commits. The first commit commits all changes, while the second commit reverts all the metadata, types, and binary changes so that you can just see which 19 source files were changed.

Once the PR is approved, I'd just drop that reduce diff commit to restore the metadata, types, and binary changes.

[shirakaba]

Self-reviewed to walk through the code changes.

[shirakaba]

ℹ️ Now we do want to build a .framework instead of a .dylib.

[DjDeveloperr]

With no other condition unsetting BUILD_FRAMEWORK, we would always produce a framework instead of dylib, is that right? How does it affect distribution of the macOS .node binary build? As of now, we produce a .dylib for macOS, and simply rename it to NativeScript.node.

[shirakaba]

Yep, we'd always produce a framework instead of a bare dylib. As for distribution, the file that @nativescript/macos-node-api distributes has changed as follows:

- "dist/macos/NativeScript.node",
+ "build/RelWithDebInfo/NativeScript.apple.node",

Usage from Node.js is the same as before, though:

import "@nativescript/macos-node-api";

console.log(NSObject.new());
console.log(NSDate.date());
console.log(typeof NSString.stringWithUTF8String("Hello, world!"));

This is made possible by the new changes to packages/macos/index.js. We now call process.dlopen() on a path that digs into the framework down to the dylib:

const path =
  "./build/RelWithDebInfo/NativeScript.apple.node/macos-arm64_x86_64/NativeScript.framework/Versions/0.1.0/NativeScript";

[shirakaba]

ℹ️ As we're prebuilding this binary on its own and bringing the Node-API implementation separately later, we need to restore GENERIC_NAPI.

This may have consequences for the Node-API distribution of @nativescript/ios. If so, please adjust it as needed so that it works for both targets.

[DjDeveloperr]

I think this is the right change to make as not all builds would require this flag anymore. Since making it backwards compatible, we don't make separate NS FFI and runtime frameworks - its all in one binary and linking should work fine unless building for platforms that dynamically load NativeScript later (GENERIC_NAPI: Node.js and co, React Native). Would be good to test a build against V8 once to make sure it compiles.

[shirakaba]

ℹ️ This now comes from build_utils.sh.

[DjDeveloperr]

LGTM 👍

[DjDeveloperr]

With no other condition unsetting BUILD_FRAMEWORK, we would always produce a framework instead of dylib, is that right? How does it affect distribution of the macOS .node binary build? As of now, we produce a .dylib for macOS, and simply rename it to NativeScript.node.

[DjDeveloperr]

I think this is the right change to make as not all builds would require this flag anymore. Since making it backwards compatible, we don't make separate NS FFI and runtime frameworks - its all in one binary and linking should work fine unless building for platforms that dynamically load NativeScript later (GENERIC_NAPI: Node.js and co, React Native). Would be good to test a build against V8 once to make sure it compiles.

[DjDeveloperr]

Makes sense here. We're loading it from a specific path in the JS entry point. macOS distribution should be fine then.