fix(0.81, ci): make react-native-macos-init job pass#2915
Open
Saadnajmi wants to merge 13 commits intomicrosoft:0.81-stablefrom
Open
fix(0.81, ci): make react-native-macos-init job pass#2915Saadnajmi wants to merge 13 commits intomicrosoft:0.81-stablefrom
Saadnajmi wants to merge 13 commits intomicrosoft:0.81-stablefrom
Conversation
The `apple` platform package was being resolved via a two-step lookup: first resolving `cli-platform-ios` to a file path, then using that file path as the search root for `cli-platform-apple`. The `require.resolve` `paths` option expects directory paths, not file paths, causing silent resolution failures when `react-native-macos` is loaded as a dependency config (e.g. via `npm install <path>`). Simplify to use the same `findCommunityPlatformPackage(spec)` pattern as `ios` and `android`, which defaults to `process.cwd()` as the search root. Since `cli-platform-apple` is a dependency of `cli-platform-ios` and gets hoisted by npm, it is directly resolvable from the project root. Fixes the "Invalid platform macos" error in the init integration test. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Saadnajmi
changed the title
Two issues prevented the macos platform from being registered when the
test project loads react-native-macos as a dependency:
1. `yarn build` rewrites package.json "exports" from ./src to ./dist
for publishing. The dist/ files use ESM syntax that requires
babel-register (only wired up in src/index.js). When the test project
loads react-native-macos via symlink, require('@react-native/
community-cli-plugin') resolves to dist/index.js which fails to load,
silently preventing the macos platform from being registered.
Fix: restore src exports after yarn build in the CI workflow.
2. The cli-platform-apple resolution used a fragile two-step lookup
(resolve cli-platform-ios file path, use as search root for
cli-platform-apple). Simplify to use the same findCommunityPlatform-
Package(spec) pattern as ios and android, which defaults to cwd.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
npm install <local-path> creates a symlink, causing Node to follow the real path back to the monorepo for module resolution. This means bundle.js loads @react-native/metro-config from the monorepo while the user's metro.config.js loads it from the test project's node_modules — two different instances. setFrameworkDefaults() (which registers the "macos" platform) targets the monorepo's instance, so the test project never sees it and xcodebuild fails with "Invalid platform macos". Using --install-links copies the package files instead, so all require() calls resolve from a single node_modules tree. Also removes debug steps that are no longer needed. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace npm install --install-links with yarn pack + yarn add. npm install <local-path> creates a symlink, and --install-links copies files but without pre-generated codegen headers. Both diverge from a normal user's install in ways that break the build: 1. Symlinks cause Node module instance duplication (bundle.js loads @react-native/metro-config from the monorepo while metro.config.js loads it from the test project — setFrameworkDefaults misses). 2. Missing React/FBReactNativeSpec/ headers (generated by prepack.js, shipped in published tarballs). Without them the codegen regenerates, but the upstream react-native's FBReactNativeSpec processes first, creating the directory — then the fork's version is skipped by shouldSkipGenerationForFBReactNativeSpec(), leaving headers without macOS-specific fields (critical, modal, defaultInputs). yarn pack runs the prepack script (generating the codegen headers) and produces a tarball identical to what npm publish would create. yarn add installs it as a regular package — no symlinks, correct headers, matching the normal user flow exactly. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The previous commit used yarn --cwd from the testcli directory, but that invokes the global yarn 1.x which refuses to run due to the packageManager field. Split into two steps: yarn pack runs from the monorepo checkout (where Yarn Berry is active), then npm install installs the tarball in the test project. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
npm pack treats directory entries in "files" as recursive globs, but yarn pack does not. Use explicit glob patterns (e.g. "scripts/cocoapods/**" instead of "scripts/cocoapods") so both tools include the full directory contents. This is the same fix as facebook#56407. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
yarn pack strips execute permissions from files. Add chmod +x after npm install to restore permissions on shell scripts that xcodebuild invokes (react-native-xcode.sh, with-environment.sh, etc.). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
npm pack preserves file permissions from the filesystem, while yarn pack (Berry) normalizes them and strips execute bits. This removes the need for the chmod workaround. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Switch back to yarn pack (consistent with publish pipeline) and restore execute permissions on shell scripts with chmod +x after install. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1 task
Saadnajmi
changed the title
The previous glob only matched scripts/*.sh and scripts/xcode/*.sh but missed scripts/react_native_pods_utils/script_phases.sh. Use find to recursively chmod all .sh files. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
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
cli-platform-appleresolution inreact-native.config.jsto use the samefindCommunityPlatformPackage(spec)pattern asiosandandroidcli-platform-iosfile path → use as search root forcli-platform-apple) passed a file path torequire.resolve'spathsoption, which expects directory paths, causing silent resolution failuresRoot cause
When
react-native-macosis installed as a dependency (e.g.npm install <path>), the CLI discovers it and loads itsreact-native.config.jsas a dependency config. Theapplevariable staysnullbecause the file-path-basedrequire.resolvefails silently, so themacosplatform is never registered. This causes the bundler to reject--platform macoswith:Test plan
🤖 Generated with Claude Code