Simplify react-native/setup-env require in community-cli-plugin#57498
Closed
huntie wants to merge 1 commit into
Closed
Simplify react-native/setup-env require in community-cli-plugin#57498huntie wants to merge 1 commit into
huntie wants to merge 1 commit into
Conversation
Summary: **Motivation** While sanity checking react#57492, I double checked why we use `path.join(ctx.reactNativePath, ...)` here when adjacent OOT platforms resolve by package name. It turns out this complexity is historic and redundant: - `reactNativePath` doesn't customize the `react-native` package name — it only resolves the `node_modules` directory. [[1]](https://github.com/react-native-community/cli/blame/main/packages/cli-tools/src/findPackageDependencyDir.ts#L81) - We now (since ~2 years ago) resolve using `{paths: [ctx.root]}`, making the manual `path.join` redundant. **This diff** Drops the `reactNativePath` option and resolves `react-native/setup-env` directly by package name. Purely a refactor. No need to pick to 0.87. Changelog: [Internal] Differential Revision: D111225671
meta-cla
Bot
added
the
CLA Signed
|
@huntie has exported this pull request. If you are a Meta employee, you can view the originating Diff in D111225671. |
|
This pull request has been merged in 4237f1a. |
react-native-bot
pushed a commit
that referenced
this pull request
Jul 14, 2026
Summary: Pull Request resolved: #57498 **Motivation** While sanity checking #57492, I double checked why we use `path.join(ctx.reactNativePath, ...)` here when adjacent OOT platforms resolve by package name. It turns out this complexity is historic and redundant: - `reactNativePath` doesn't customize the `react-native` package name — it only resolves the `node_modules` directory. [[1]](https://github.com/react-native-community/cli/blame/main/packages/cli-tools/src/findPackageDependencyDir.ts#L81) - We now (since ~2 years ago) resolve using `{paths: [ctx.root]}`, making the manual `path.join` redundant. **This diff** Drops the `reactNativePath` option and resolves `react-native/setup-env` directly by package name. Purely a refactor. No need to pick to 0.87. Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D111225671 fbshipit-source-id: ff0a385172228f51cde747266543cc615be7ee38
meta-codesync Bot
pushed a commit
that referenced
this pull request
Jul 15, 2026
#57557) Summary: Pull Request resolved: #57557 Fresh projects **redbox on launch** — e.g.: ``` Failed to call into JavaScript module method RCTDeviceEventEmitter.emit(). Module has not been registered as callable. Registered callable JavaScript modules (n = 1): AppRegistry. ``` (The named module varies — `HMRClient.setup()`, `RCTDeviceEventEmitter.emit()` — it's whichever callable module native calls first.) `n = 1: AppRegistry` is the tell: **core initialization never runs**. ## Root cause (#57475) Core init runs via Metro's `serializer.getModulesRunBeforeMainModule`. Metro (`metro/src/lib/getAppendScripts.js`) only emits the run-before `__r()` for a module **already present in the bundle graph**, and silently skips it otherwise: ```js const paths = [...options.runBeforeMainModule, entryPoint]; for (const path of paths) { if (modules.some((module) => module.path === path)) { // only if already in the graph /* __r(moduleId) */ } } ``` **#57475 switched the run-before target from `Libraries/Core/InitializeCore` → `src/setup-env.js`. - `InitializeCore.js` **is** reachable (imported by `Libraries/ReactPrivate/ReactNativePrivateInitializeCore.js`). - `src/setup-env.js` is imported by **nothing** → not in the graph → silently skipped → core init never runs. The two modules are functionally identical (both call `setUpDefaultReactNativeEnvironment().default()`), so only *reachability* changed. #57498 was cosmetic (same resolved file) and does not fix this. ### Evidence (bundle tail) | Run-before target | Bundle tail | Boots? | |---|---|---| | `setup-env` (current) | `__r(0);` | ❌ | | `InitializeCore` (this PR) | `__r(<InitializeCore>); __r(0);` | ✅ | Verified end-to-end via `test-release-local -t RNTestProject -p iOS`. Ruled out: Metro cache (cold `--reset-cache` identical), stale Metro, and #57484 (`./src/*` exports removal). Reproduces via the `react-native-community/cli` bundling path (OSS `react-native start`); internal Meta bundling is unaffected, which is why CI/internal stayed green. ## Scope — interim stopgap Only the **internal Metro bootstrap target** reverts to `InitializeCore`. The public `react-native/setup-env` entry point and its deprecation of `InitializeCore` are **unchanged**. The **durable fix** is to make `setup-env` graph-reachable (or make Metro treat `getModulesRunBeforeMainModule` entries as graph roots) — which will then allow `InitializeCore` to be removed as intended. cc huntie (`setup-env` stack owner). A cherry-pick of this is also up against `0.87-stable` (#57553). ## Changelog [General][Fixed] - Fix apps failing to boot ("... not registered as callable") caused by core init not running. Reviewed By: christophpurrer Differential Revision: D112002434 fbshipit-source-id: ea3559ef74d31f2c0f9af78aa0a020f4b322e7e0
react-native-bot
pushed a commit
that referenced
this pull request
Jul 15, 2026
#57557) Summary: Pull Request resolved: #57557 Fresh projects **redbox on launch** — e.g.: ``` Failed to call into JavaScript module method RCTDeviceEventEmitter.emit(). Module has not been registered as callable. Registered callable JavaScript modules (n = 1): AppRegistry. ``` (The named module varies — `HMRClient.setup()`, `RCTDeviceEventEmitter.emit()` — it's whichever callable module native calls first.) `n = 1: AppRegistry` is the tell: **core initialization never runs**. ## Root cause (#57475) Core init runs via Metro's `serializer.getModulesRunBeforeMainModule`. Metro (`metro/src/lib/getAppendScripts.js`) only emits the run-before `__r()` for a module **already present in the bundle graph**, and silently skips it otherwise: ```js const paths = [...options.runBeforeMainModule, entryPoint]; for (const path of paths) { if (modules.some((module) => module.path === path)) { // only if already in the graph /* __r(moduleId) */ } } ``` **#57475 switched the run-before target from `Libraries/Core/InitializeCore` → `src/setup-env.js`. - `InitializeCore.js` **is** reachable (imported by `Libraries/ReactPrivate/ReactNativePrivateInitializeCore.js`). - `src/setup-env.js` is imported by **nothing** → not in the graph → silently skipped → core init never runs. The two modules are functionally identical (both call `setUpDefaultReactNativeEnvironment().default()`), so only *reachability* changed. #57498 was cosmetic (same resolved file) and does not fix this. ### Evidence (bundle tail) | Run-before target | Bundle tail | Boots? | |---|---|---| | `setup-env` (current) | `__r(0);` | ❌ | | `InitializeCore` (this PR) | `__r(<InitializeCore>); __r(0);` | ✅ | Verified end-to-end via `test-release-local -t RNTestProject -p iOS`. Ruled out: Metro cache (cold `--reset-cache` identical), stale Metro, and #57484 (`./src/*` exports removal). Reproduces via the `react-native-community/cli` bundling path (OSS `react-native start`); internal Meta bundling is unaffected, which is why CI/internal stayed green. ## Scope — interim stopgap Only the **internal Metro bootstrap target** reverts to `InitializeCore`. The public `react-native/setup-env` entry point and its deprecation of `InitializeCore` are **unchanged**. The **durable fix** is to make `setup-env` graph-reachable (or make Metro treat `getModulesRunBeforeMainModule` entries as graph roots) — which will then allow `InitializeCore` to be removed as intended. cc huntie (`setup-env` stack owner). A cherry-pick of this is also up against `0.87-stable` (#57553). ## Changelog [General][Fixed] - Fix apps failing to boot ("... not registered as callable") caused by core init not running. Reviewed By: christophpurrer Differential Revision: D112002434 fbshipit-source-id: ea3559ef74d31f2c0f9af78aa0a020f4b322e7e0
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary:
Motivation
While sanity checking #57492, I double checked why we use
path.join(ctx.reactNativePath, ...)here when adjacent OOT platforms resolve by package name.It turns out this complexity is historic and redundant:
reactNativePathdoesn't customize thereact-nativepackage name — it only resolves thenode_modulesdirectory. [1]{paths: [ctx.root]}, making the manualpath.joinredundant.This diff
Drops the
reactNativePathoption and resolvesreact-native/setup-envdirectly by package name.Purely a refactor. No need to pick to 0.87.
Changelog: [Internal]
Differential Revision: D111225671