[genaris]

@openwallet-foundation/askar-react-native now ships a TurboModule generated with codegen, instead of a legacy module that React Native loads through its interop layer. It builds on #96, which made the bindings install in bridgeless mode on iOS.

The spec in src/specs/NativeAskar.ts declares install(). On iOS, the module returns the generated NativeAskarSpecJSI and still installs the bindings in installJSIBindingsWithRuntime:. On Android, it extends the generated NativeAskarSpec and implements TurboModuleWithJSIBindings, so React Native installs the bindings when it creates the module (available since React Native 0.76, so the >= 0.77 peer range doesn't change). On the New Architecture, JS no longer has to call install().

The old architecture keeps working through the bridge install(). On Android, a copy of the generated spec in src/oldarch stands in for codegen there.

[changeset-bot]

🦋 Changeset detected

Latest commit: 5403c3f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@openwallet-foundation/askar-react-native	Patch
@openwallet-foundation/askar-nodejs	Patch
@openwallet-foundation/askar-shared	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[TimoGlastra]

I don't really see a JS interface for all the methods, just the install? Doesn't codegen generate the interface for all methods, we still manually register them on the module on the c++ side right?

Once we drop support for the old arch, can we drop the Java and object c layers?

[TimoGlastra]

I think the CI failure is because of callstackincubator/react-native-harness#299

[genaris]

I don't really see a JS interface for all the methods, just the install? Doesn't codegen generate the interface for all methods, we still manually register them on the module on the c++ side right?

Only for what's in the spec, and the spec only has install(). The functions are still registered by hand in C++, as before: they're in the JSI HostObject that install puts on the global object. This PR only changes how React Native loads the module.

Once we drop support for the old arch, can we drop the Java and object c layers?

Mostly. On Android we can drop them completely and ship a pure C++ TurboModule, which React Native and Expo autolink. On iOS, React Native still finds a library's modules through an Objective-C class, so a small provider stays.

[genaris]

I think the CI failure is because of callstackincubator/react-native-harness#299

I've applied a patch to work around this. Will create a PR upstream to see if it is an appropriate solution.