chore(mobile): resolve react-native to 0.79.5 in lockfile + pods#14365
Conversation
The previous RN upgrade bumped packages/mobile/package.json to
react-native 0.79.5 but the lockfile and ios/Podfile.lock remained
pinned at 0.78.3 (npm declined to bump under legacy-peer-deps without
manual intervention).
- Regenerate package-lock.json so react-native + @react-native/*
resolve at 0.79.5 (hoisted to the monorepo node_modules).
- Regenerate ios/Podfile.lock via pod install so React-Core, hermes,
RCTDeprecation, FBLazyVector etc. land on 0.79.5. pod install also
retargets REACT_NATIVE_PATH in the Xcode project to the hoisted
node_modules path.
- Point the android/app build.gradle react {} block at the hoisted
node_modules location (root, reactNativeDir, cliFile) so the
React-Native Gradle plugin can find ReactAndroid/gradle.properties.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
- packages/mobile/package.json: 1.5.179 -> 1.5.180 (CodePush/OTA) - ios/AudiusReactNative/Info.plist: 1.1.192 -> 1.1.193 (CFBundleShortVersionString) - android/app/build.gradle versionName: 1.1.528 -> 1.1.529 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Replace useRef<NodeJS.Timeout | null>(null) with useRef<ReturnType<typeof setTimeout> | null>(null). NodeJS.Timeout assumes the @types/node global setTimeout overload is loaded. The dependency-graph shifts in this PR (RN 0.78.3 -> 0.79.5) left @types/node out of TypeScript's auto-include set for the harmony rollup build, so setTimeout resolved to the DOM lib's `number` return, which is not assignable to NodeJS.Timeout. ReturnType<typeof setTimeout> infers whichever return type the active lib provides and works in both DOM-only and Node-augmented builds. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
🌐 Web preview readyPreview URL: https://audius-web-preview-pr-14365.audius.workers.dev Unique preview for this PR (deployed from this branch). |
The Xcode build phase used hardcoded
\${SRCROOT}/../node_modules/react-native/scripts/... which only worked
when react-native was installed under packages/mobile/node_modules.
Since the RN 0.79.5 lockfile regen hoisted react-native to the
monorepo root, that path no longer resolves and 'react-native run-ios'
fails with xcodebuild exit code 65 in the bundle phase.
Switch to \$REACT_NATIVE_PATH (already configured in the project build
settings to point at the hoisted node_modules/react-native), matching
the RN 0.79.5 template.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The Metro config aliased 'react-native' to
packages/mobile/node_modules/react-native, but the RN 0.79.5 lockfile
regen hoisted react-native to the monorepo root, so that directory no
longer exists. Metro could not load the transformer and bundling
crashed with "Cannot read properties of undefined (reading
'transformFile')" in Bundler.transformFile.
Switch the alias to resolveModule('react-native'), matching how 'react'
is already aliased.
Note: developers running Metro will need to clear the cache after
pulling (e.g. 'npm run mobile:clear-cache' or 'react-native start
--reset-cache') for the new resolution to take effect.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
react-native-svg-transformer (hoisted to the monorepo root) does an
untyped require('@react-native/metro-babel-transformer') at module load
time. With the RN 0.79 install layout, the transformer lived only in
packages/mobile/node_modules, so Node could not find it from the root
node_modules location and Metro failed to construct its transformer
with 'Cannot read properties of undefined (reading transformFile)'.
Declare @react-native/metro-babel-transformer at root devDeps so it
hoists alongside react-native-svg-transformer.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
Caution Review the following alerts detected in dependencies. According to your organization's Security Policy, you must resolve all "Block" alerts before proceeding. It is recommended to resolve "Warn" alerts too. Learn more about Socket for GitHub.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Summary
The previous RN upgrade (#14303) bumped
packages/mobile/package.jsontoreact-native@0.79.5but the lockfile andios/Podfile.lockstayed pinned at0.78.3— a plainnpm installunderlegacy-peer-deps=truewould not bump them.This PR resolves the iOS/Android package versions to actually match the declared
0.79.5:package-lock.json— regenerated soreact-nativeand@react-native/*(gradle-plugin, codegen, community-cli-plugin, virtualized-lists, etc.) resolve to0.79.5. The deps now hoist to the monorepo rootnode_modules/instead of living underpackages/mobile/node_modules/.packages/mobile/ios/Podfile.lock— regenerated viapod install;React-Core,hermes-engine,RCTDeprecation,FBLazyVector,React-Fabric, etc. are now0.79.5.React-hermes,React-jsi, andReact-renderercssare now declared as explicit dependencies ofReact(new in 0.79).packages/mobile/ios/AudiusReactNative.xcodeproj/project.pbxproj—pod installretargetedREACT_NATIVE_PATHto the hoistednode_modules/react-nativelocation (${PODS_ROOT}/../../../../node_modules/react-native).packages/mobile/android/app/build.gradle— setroot,reactNativeDir, andcliFilein thereact { }block so the React Native Gradle plugin can findReactAndroid/gradle.propertiesat the hoisted top-levelnode_modules/react-native. Without this,:app:downloadAar(and any other Gradle task) failed because the plugin's default convention looks underpackages/mobile/node_modules/react-native.How I verified
npm installcompletes without warnings;node_modules/react-native/package.jsonshows"version": "0.79.5".cd packages/mobile/android && ./gradlew :app:downloadAar→BUILD SUCCESSFUL.bundle exec pod install(run automatically bypostinstall) regeneratesPodfile.lockcleanly; allReact-Core (= 0.79.5).Test plan
npm run ios:devboots and launches the appnpm run android:devboots and launches the app🤖 Generated with Claude Code