hi@Freddy03h,

Thanks for reviewing the PR. Let me give you more insights.

This PR introduces ReScript support for React Native's codegen system. Currently, React Native codegen works by parsing TypeScript or Flow files using respective AST parsers (likereact-native-codegen/src/parsers/flow) and converting them to a standardized Flow AST representation for native code generation. The system has strict prerequisites including TurboModule extension, proper module registration patterns, and HostComponent checks that must be satisfied for successful codegen.

I've implemented a Flow-like AST parser for ReScript that translates ReScript syntax into the same Flow AST format that the existing codegen pipeline expects. This allows developers to write native module and component specifications in ReScript while maintaining full compatibility with the existing codegen infrastructure.

Could you please review the implementation and suggest any improvements? I'm particularly interested in feedback on the best Rescript syntax for this for AST transformation logic and whether the ReScript-to-Flow AST mapping aligns well with the existing codegen expectations.

NativeTurboModule.res

openReactNativeopenTurboModuletypespec= {...turboModule,initialise: ((option<string>,option<string>)=>unit)=>unit,getSession: (Js.Dict.t<string>,Js.Dict.t<string>,array<Js.Json.t>,    (option<string>,option<string>)=>unit,  )=>unit,exit:string=>unit,}lethyperHeadlessModule:get<spec>=get("HyperHeadlessModule")

NativeButtonComponent.res

openReactNativeopenCodegenNativeComponentmoduleNativeButton= {typeprops= {...View.viewProps,title:string,color?:string,  }letmake:nativeComponentType<props>=codegenNativeComponent("NativeButton", ~options=makeOptions(~interfaceOnly=true, ()))}

hi@ricku44
Can you tell me what's missing from the playground examples I provided?

Shared code works well, I'm wondering how should we add ReScript-specific validations that React Native enforces.

Codegen supports TypeScript and Flow primarily and not JS maybe for type enforcement at the JavaScript-native boundary, preventing runtime crashes and ensuring performance.

NativeModule and NativeComponent registration patterns involves getConstants and ViewProps enforcement.

Works ✅

importtype {TurboModule}from'react-native';import {TurboModuleRegistry}from'react-native';exportinterfaceSpecextendsTurboModule {}exportdefaultTurboModuleRegistry.getEnforcing<Spec>('NativeLocalStorage');

Fails ❌

importtype {TurboModule}from'react-native';import {TurboModuleRegistry}from'react-native';exportinterfaceSpec {}exportdefaultTurboModuleRegistry.getEnforcing<Spec>('NativeLocalStorage');

Fails ❌

importtype {TurboModule}from'react-native';import {TurboModuleRegistry}from'react-native';exportinterfaceSpecextendsTurboModule {}exportdefaultTurboModuleRegistry.getEnforcing('NativeLocalStorage');

Fails ❌

import {TurboModuleRegistry}from'react-native';exportinterfaceSpec {getConstants(): {};}exportdefaultTurboModuleRegistry.getEnforcing('NativeLocalStorage');

Works ✅

importtype {ViewProps}from'react-native';import {codegenNativeComponent}from'react-native';exportinterfaceNativePropsextendsViewProps {sourceURL?:string;}exportdefaultcodegenNativeComponent<NativeProps>('CustomWebView');

Fails ❌

import {codegenNativeComponent}from'react-native';exportinterfaceNativeProps {sourceURL?:string;}exportdefaultcodegenNativeComponent<NativeProps>('CustomWebView');

Fails ❌

importtype {ViewProps}from'react-native';import {codegenNativeComponent}from'react-native';exportinterfaceNativePropsextendsViewProps {sourceURL?:string;}exportdefaultcodegenNativeComponent('CustomWebView');

I think this is more than just bindings.
It should be on an other project in the organization (mayberescript-react-native-codegen ?).

I can't help you with the AST Parser or even if you want to use genType (I never used it).

The only things I can't tell about your bindings is that you should prefernullable instead ofoption for values that cames from JShttps://rescript-lang.org/docs/manual/v11.0.0/interop-cheatsheet#nullable inNativeTurboModule.res
And inNativeButtonComponent.res, you should provide directly the record instead of using non-necessarymakeOptions func.

Should we make the flow consistent in NativeModule.res as well?

@Freddy03h PR is ready for review.