Summary:
Changelog: [GENERAL] [FIXED] - Fixed babel plugin validation error when coverage instrumentation is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/53381
### Problem
[Workplace post](https://fb.workplace.com/groups/235694244595999/permalink/1278937163605030/)
React Native tests were failing **only when coverage collection was enabled** with the error:
`'Commands' is a reserved export and may only be used to export the result of codegenNativeCommands.`
### Root Cause
The React Native Babel plugin's `codegenNativeCommands` validation logic only handled direct `CallExpression` AST nodes. When coverage instrumentation was enabled, it transformed:
**Normal code:**
`export const Commands = codegenNativeCommands<NativeCommands>({...})`
**With coverage:**
`export const Commands = (cov_xxx().s[0]++, codegenNativeCommands<NativeCommands>({...}))`
The plugin failed to recognize the valid `codegenNativeCommands` call wrapped in a `SequenceExpression` by coverage instrumentation.
### **Solution**
Added `isCodegenNativeCommandsDeclaration` function to handle:
1. **Coverage instrumentation**: `SequenceExpression` nodes containing the function call
2. **Flow type casts**: `TypeCastExpression` and `AsExpression`
3. **TypeScript assertions**: `TSAsExpression`
4. **Direct calls**: Original `CallExpression` (backward compatibility)
Reviewed By: andrewdacenko
Differential Revision: D80572666
fbshipit-source-id: 465f4312a0229d8a92e495c685f46b607ce326e4
Summary:
Changelog: [Internal] - Remove all imports back to CJS for changelog in 0.72
We are reverting these imports as it may regress perf as we don't have a recommended inlining solution for ES modules at the current time.
Reviewed By: NickGerleman
Differential Revision: D43630911
fbshipit-source-id: ff3bb80009f327c4d51dad21f2cd287ce46d5964
Summary:
Forgot to delete these snapshot tests in D25915169 (https://github.com/facebook/react-native/commit/e67fc7cadadab065901fc67d5f1485c696197362). They are no longer necessary, because we're deleting the JS TurboModule codegen.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25920310
fbshipit-source-id: 66f6fa3fcba5b53210798a204e4f76e4595b3f25
Summary:
## Changes
1. In the NativeModule spec parser, the moduleName is now being extracted from the TurboModuleRegistry.get<Spec>(...) call by examining the Flow ast node. Previously, we used regex parsing, which was unsafe because it could be fooled by TurboModuleRegistry.get<Spec>(...) calls in comments.
2. The logic to parse and validate the TurboModuleRegistry.get<Spec>(...) call is now centralized in the NativeModule Spec Parser (it was removed from the react-native-modules ESLint rule). The linter is now only responsible for three things:
1. Detecting if a JavaScript file contains a TurboModuleRegistry.get<Spec> call or a TurboModule interface, and if so
2. Running the NativeModule spec parser on it.
3. It also validates that the Module spec's filename starts with the prefix "Native".
The React Native Modules linter now completely delegates to the NativeModules Spec parser, without doing any error checking of its own. If an error is reported by the React Native Modules linter, and that error doesn't have anything to do with the "Native" prefix, then it *must* be addressed. Otherwise, it will cause the NativeModule Spec Parser to fail on that particular spec.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D25153243
fbshipit-source-id: da74dbb66b1d8dca3a2b1952402222c6696b73d6
Summary:
## New Functionality
- Detect if the JS file represents a NativeModule spec.
- **Note:** A JS file is a NativeModule spec if it contains a flow `interface` that extends `TurboModule`. This logic is copied over from the OSS Codegen, here: https://github.com/facebook/react-native/blob/7ccb67a49c087e7ee536c2ffb71717e68a79324b/packages/react-native-codegen/src/parsers/flow/index.js#L60-L75
- For all NativeModule specs, generate the spec's schema using the OSS Codegen for Modules, and conditionally inline it into every `TurboModuleRegistry.get(Enforcing)?` call in the spec, like so:
**Before:**
```
/**
* flow
*/
import type {TurboModule} from 'RCTExport';
export interface Spec extends TurboModule {
//...
}
export default TurboModuleRegistry.get<Spec>('FooModule');
```
**After:**
```
/**
* flow
*/
import type {TurboModule} from 'RCTExport';
export interface Spec extends TurboModule {
//...
}
export default TurboModuleRegistry.get<Spec>('FooModule', __getModuleShape());
function __getModuleShape() {
if (!(global.RN$EnableTurboModuleJSCodegen === true)) {
return undefined;
}
return {...};
}
```
Changelog: [General][Added] Extend react-native/babel-plugin-codegen to generate TurboModule JS codegen
Reviewed By: TheSavior
Differential Revision: D22803845
fbshipit-source-id: 18c157a1dbfcc575012184de31c38908acd53c36
Summary:
This babel plugin will also take care of the JS TurboModule Codegen. Therefore, we should rename this into something more generic.
Changelog:
[General][Changed] Rename babel-plugin-inline-view-configs to react-native/babel-plugin-codegen
Reviewed By: rickhanlonii, cpojer
Differential Revision: D22803209
fbshipit-source-id: 416c97fea6fa0820d25bbc91033a0cbbbbbff825
Umar Mohammad
Luna Wei
Andres Suarez
Ramanpreet Nara