chore: upgrade to react native 81 and expo 54 #6875
Conversation
Rohit3523
had a problem deploying
to
approve_e2e_testing
GitHub Actions
Error
WalkthroughThis PR performs a comprehensive upgrade of the Android build toolchain, iOS project configuration, and project dependencies. Updates include Android SDK/build tools (35→36), Kotlin version, Gradle wrapper, React Native (0.79→0.81), Expo (53→54), React (18→19), iOS Xcode project configuration, and introduction of new build flags and Expo module integrations. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Rohit3523
temporarily deployed
to
approve_e2e_testing
GitHub Actions
Inactive
Rohit3523
temporarily deployed
to
approve_e2e_testing
GitHub Actions
Inactive
Rohit3523
requested a deployment
to
approve_e2e_testing
GitHub Actions
Waiting
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
android/app/src/main/java/chat/rocket/reactnative/MainApplication.kt (1)
60-80: ReplaceloadReactNative()with the official React Native 0.81 initialization pattern.The current initialization using direct
loadReactNative(this)calls is outdated. React Native 0.81 removed this pattern in favor of the new template structure. Replace the custom initialization with:private val mReactNativeHost = DefaultReactNativeHost(this, BuildConfig.IS_NEW_ARCHITECTURE_ENABLED) override fun onCreate() { super.onCreate() Bugsnag.start(this) MMKVKeyManager.initialize(this) SoLoader.init(this, false) if (BuildConfig.IS_NEW_ARCHITECTURE_ENABLED) { DefaultNewArchitectureEntryPoint.load() } mReactNativeHost.reactInstanceManager.addReactInstanceEventListener( object : ReactInstanceEventListener { override fun onReactContextInitialized(context: ReactContext) { CustomPushNotification.setReactContext(context as ReactApplicationContext) } } ) ApplicationLifecycleDispatcher.onApplicationCreate(this) }Refer to the React Native 0.81 Upgrade Helper for the complete MainApplication.kt template changes, or check the migration docs for DefaultReactNativeHost and DefaultNewArchitectureEntryPoint requirements.
package.json (1)
87-124: React 19 compatibility is confirmed; address reanimated version alignment.React Native 0.81.5 officially supports React 19.1.0 (support introduced in 0.78/0.80 series). react-native-gesture-handler@2.28.0 and react-native-reanimated@4.1.1 are both compatible with this setup. However, ensure:
- The react and react-native-renderer versions are precisely aligned to prevent runtime mismatches (common with React 19 updates when reanimated is present)
- Native modules are rebuilt after the update (clean Metro cache, reinstall node_modules, rebuild the app)
- Testing covers React 19-specific behavioral changes (refs, Suspense, concurrent features)
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (3)
android/gradle/wrapper/gradle-wrapper.jaris excluded by!**/*.jarios/Podfile.lockis excluded by!**/*.lockyarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (20)
android/app/src/debug/AndroidManifest.xmlandroid/app/src/main/AndroidManifest.xmlandroid/app/src/main/java/chat/rocket/reactnative/MainApplication.ktandroid/build.gradleandroid/gradle.propertiesandroid/gradle/wrapper/gradle-wrapper.propertiesandroid/gradlewandroid/gradlew.batapp.jsonbabel.config.jsios/NotificationService/Info.plistios/RocketChatRN.xcodeproj/project.pbxprojios/RocketChatRN/Info.plistios/ShareRocketChatRN/Info.plistmetro.config.jspackage.jsonpatches/@rocket.chat+message-parser+0.31.31.patchpatches/expo-file-system+19.0.21.patchpatches/expo-image+2.3.2.patchpatches/react-native+0.81.5.patch
💤 Files with no reviewable changes (3)
- patches/expo-image+2.3.2.patch
- android/app/src/debug/AndroidManifest.xml
- patches/@rocket.chat+message-parser+0.31.31.patch
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-12-17T15:56:22.578Z
Learnt from: OtavioStasiak
Repo: RocketChat/Rocket.Chat.ReactNative PR: 6499
File: app/containers/ServerItem/index.tsx:34-36
Timestamp: 2025-12-17T15:56:22.578Z
Learning: In the Rocket.Chat React Native codebase, for radio button components on iOS, include the selection state ("Selected"/"Unselected") in the accessibilityLabel instead of using accessibilityState={{ checked: hasCheck }}, because iOS VoiceOver has known issues with accessibilityRole="radio" + accessibilityState that prevent correct state announcement.
Applied to files:
app.json
🔇 Additional comments (19)
android/app/src/main/java/chat/rocket/reactnative/MainApplication.kt (1)
8-8: LGTM: Correct import for React Native 0.81 entry point.The import of
loadReactNativefromReactNativeApplicationEntryPointaligns with the React Native 0.81 migration pattern.android/gradle.properties (1)
48-51: Appropriate configuration for Android edge-to-edge support.Setting
edgeToEdgeEnabled=falseis a conservative and safe choice for the initial RN 0.81 upgrade. The edge-to-edge display feature (Android 15+) can cause layout issues if the app isn't specifically designed to handle system bar insets. The documentation comment correctly notes the ReactActivity requirement.Consider enabling this in a future PR after:
- Testing layout behavior with system bars
- Adding proper insets handling using react-native-safe-area-context
- Verifying all screens render correctly in edge-to-edge mode
patches/react-native+0.81.5.patch (2)
1-26: Accessibility role patch addresses iOS 26 Switch layout issue.This patch correctly fixes an iOS accessibility bug where role updates weren't triggering view updates when only the role string changed (not the traits). The enhanced condition now checks both
accessibilityRoleTraitsand the role string, ensuring proper updates.This directly addresses issue #6874 regarding Switch component layout problems on iOS 26, which was attributed to React Native 0.79 behavior. The patch ensures that accessibility elements properly refresh when roles change.
Based on learnings, this codebase has previously addressed iOS VoiceOver accessibility issues by customizing how accessibility states are announced.
27-38: CocoaPods Info.plist exclusion prevents build failures.Adding
.xcframeworkand.frameworkto the excluded paths is a standard fix for React Native 0.81 iOS builds. This prevents CocoaPods from incorrectly processing Info.plist files inside framework bundles, which can cause build failures or warnings during pod installation.metro.config.js (1)
7-9: Proper Metro config pattern for RN 0.81.This refactoring correctly modernizes the Metro configuration by:
- Using
getDefaultConfig(__dirname)to obtain the base configuration- Deriving
sourceExtsfromdefaultConfig.resolver.sourceExtsinstead of importing it directly- Maintaining existing functionality (appending 'mjs' extension)
This approach is more maintainable and aligns with the recommended Metro configuration pattern for React Native 0.81 and Expo 54.
app.json (1)
3-3: Plugin setup is correct and complete.Both
@react-native-community/datetimepicker(8.4.4) andexpo-web-browser(~15.0.10) are properly installed in package.json dependencies and correctly declared in the plugins array. Platform-specific configurations will be automatically handled by Expo prebuild during native builds.babel.config.js (1)
11-11: No action needed. The babel config change is correct for your Reanimated v4.1.1 setup.The project uses Reanimated v4.1.1 with react-native-worklets v0.7.1, so
react-native-worklets/pluginis the required and correct plugin. Reanimated v4+ depends on and requires this plugin. The metro config usingwrapWithReanimatedMetroConfigis also correct and aligns with Reanimated v4 requirements.android/gradlew.bat (1)
1-5: LGTM - Gradle wrapper script modernized.The changes align with modern Gradle wrapper patterns:
- Added appropriate MIT license header for Meta/React Native code
- Updated invocation to execute the wrapper JAR directly with
-jarinstead of using classpath-based invocation- Consistent with the Gradle 8.14.3 upgrade
These are standard improvements that come with newer Gradle wrapper versions.
Also applies to: 78-82
ios/NotificationService/Info.plist (1)
36-37: Verify new architecture compatibility and testing before merge.
RCTNewArchEnabledis enabled across all iOS targets (main app, ShareExtension, NotificationService) and Android, indicating this is an intentional app-wide enablement as part of the RN 0.81 migration strategy. However, the New Architecture introduces significant changes (Fabric renderer, TurboModules, Codegen) with known compatibility challenges:
- Third-party native libraries often require updates or interop layers for Fabric/TurboModules support
- Performance regressions and UI jank have been reported on some devices
- Build failures can occur from Codegen/C++ header mismatches or dependency version conflicts
Before merging, confirm:
- All native dependencies have been updated to support the New Architecture (check library changelogs and migration guides)
- Full testing completed, including performance regression testing
- Pod install and gradle builds execute cleanly with
RCT_NEW_ARCH_ENABLED=1- Known incompatible libraries have been replaced or have workarounds
package.json (1)
29-76: Expo 54 package compatibility confirmed. The specified versions (expo-image 3.0.11, expo-notifications 0.32.15, expo-camera 17.0.10) are compatible with Expo SDK 54. For ongoing dependency consistency, consider runningnpx expo-doctorto validate version alignment with the SDK.patches/expo-file-system+19.0.21.patch (1)
14-22: The singleton OkHttpClient pattern is correct for this use case; remove the fundamental concerns.The patch correctly implements a recommended pattern. OkHttp is explicitly designed to be shared as a single instance across the application and is thread-safe for concurrent requests. Per OkHttp documentation and Expo SDK 54 guidance, a global singleton with a shared connection pool and thread dispatcher is the intended design—not a workaround.
The public
setOkHttpClient()setter is acceptable for initialization-time configuration. If you want to add a safety guard, consider wrapping the setter to ensure it's only called before any requests begin, but this is optional given the expected initialization flow of native modules.The null safety concern for
clientaccess throughout the module is valid and should be verified, but the core singleton pattern itself requires no changes.Likely an incorrect or invalid review comment.
android/gradlew (1)
117-117: LGTM: Standard Gradle wrapper update.The CLASSPATH and invocation changes are part of the standard Gradle wrapper update pattern (to version 8.14.3 based on the PR context). These modifications align with how newer Gradle versions structure their wrapper execution.
Also applies to: 216-216
ios/ShareRocketChatRN/Info.plist (1)
65-66: New architecture enabled for Share extension.
RCTNewArchEnabledis now enabled for the Share extension target. Ensure the share extension code is compatible with React Native's new architecture, particularly any native modules or UI components used within the extension.ios/RocketChatRN/Info.plist (1)
7-8: Confirm the app requests higher display frame rates via CADisplayLink or CAAnimation APIs.
CADisableMinimumFrameDurationOnPhoneis valid and correctly configured—it permits iPhones to request display refresh rates >60 Hz on ProMotion devices. However, the key alone does not enable higher refresh rates; the app must actively request them usingCADisplayLink.preferredFrameRateRangeorCAAnimation.preferredFrameRateRange(iOS 15+) for this configuration to have any effect. Verify that the corresponding frame-rate requests are implemented to ensure this change resolves the intended issue. The connection to issue #6874 cannot be verified from the codebase and requires external context.ios/RocketChatRN.xcodeproj/project.pbxproj (5)
1620-1620: RNCAsyncStorage resource bundle additions look correct.The
RNCAsyncStorage_resources.bundleis correctly added to all three Copy Pods Resources phases (RocketChatRN, Rocket.Chat, and NotificationService) in both input and output paths. This is expected when upgrading dependencies that now include resource bundles.Also applies to: 1654-1654, 1845-1845, 1879-1879, 1990-1990, 2024-2024
1682-1691: Expo Configure project phase for RocketChatRN target is properly configured.The input paths now include environment files (
.xcode.env,.xcode.env.local), entitlements, and the Expo configure script. The output path correctly referencesExpoModulesProvider.swiftgeneration. This aligns with Expo 54 requirements.
1907-1916: Expo Configure project phase for Rocket.Chat target mirrors the RocketChatRN configuration correctly.Consistent with the RocketChatRN target changes, referencing the appropriate Pods-defaults-Rocket.Chat paths.
1931-1940: Expo Configure project phase for NotificationService target is properly configured.Correctly references
NotificationService.entitlementsand the NotificationService-specific Pods configuration. The pattern is consistent with the other targets.
3283-3284: React-runtimeexecutor header search paths added for React Native 0.81.The
React-runtimeexecutorframework headers are correctly added to both Debug and Release project-level configurations at lines 3283-3284 and 3353-3354 respectively. The Podfile.lock confirms React-runtimeexecutor (0.81.5) is properly resolved as a dependency, which is required for React Native 0.81's new architecture support.
| android:requestLegacyExternalStorage="true" | ||
| android:supportsRtl="true" | ||
| android:theme="@style/AppTheme" | ||
| android:usesCleartextTraffic="${usesCleartextTraffic}" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for usesCleartextTraffic definition in all relevant Gradle files
echo "=== Checking gradle.properties files ==="
find . -name "gradle.properties" -type f | xargs grep -l "usesCleartextTraffic" 2>/dev/null || echo "Not found in gradle.properties"
echo -e "\n=== Checking build.gradle files ==="
find . -name "build.gradle*" -type f | xargs grep -n "usesCleartextTraffic" 2>/dev/null || echo "Not found in build.gradle"
echo -e "\n=== Checking AndroidManifest.xml ==="
find . -name "AndroidManifest.xml" -type f | xargs grep -n "usesCleartextTraffic" 2>/dev/null
echo -e "\n=== Checking build.gradle files for manifestPlaceholders ==="
find . -name "build.gradle*" -type f | xargs grep -n "manifestPlaceholders" 2>/dev/null || echo "Not found"
echo -e "\n=== Listing all gradle.properties files ==="
find . -name "gradle.properties" -type fRepository: RocketChat/Rocket.Chat.ReactNative
Length of output: 596
🏁 Script executed:
#!/bin/bash
# Examine the build.gradle file around the manifestPlaceholders definition
echo "=== Full android/app/build.gradle snippet around manifestPlaceholders ==="
sed -n '85,105p' android/app/build.gradle
echo -e "\n=== Check entire defaultConfig block ==="
sed -n '/defaultConfig/,/}/p' android/app/build.gradle | head -50Repository: RocketChat/Rocket.Chat.ReactNative
Length of output: 1441
Add usesCleartextTraffic to manifestPlaceholders in android/app/build.gradle.
The placeholder ${usesCleartextTraffic} is used in AndroidManifest.xml but is not defined in the manifestPlaceholders map. Update android/app/build.gradle line 95 to include this variable:
manifestPlaceholders = [BugsnagAPIKey: BugsnagAPIKey as String, usesCleartextTraffic: "false"]Without this definition, the build will fail or the placeholder will remain unexpanded in the manifest.
🤖 Prompt for AI Agents
In android/app/src/main/AndroidManifest.xml around line 31 the placeholder
${usesCleartextTraffic} is referenced but not defined; update
android/app/build.gradle (around line 95) to add usesCleartextTraffic to the
manifestPlaceholders map so the placeholder is defined (e.g., add
usesCleartextTraffic: "false" alongside the existing BugsnagAPIKey entry) and
re-run the build.
| buildToolsVersion = "36.0.0" | ||
| minSdkVersion = 24 | ||
| compileSdkVersion = 35 | ||
| targetSdkVersion = 35 | ||
| compileSdkVersion = 36 | ||
| targetSdkVersion = 36 | ||
| ndkVersion = "27.1.12297006" | ||
| kotlinVersion = "2.0.21" | ||
| kotlinVersion = "2.1.20" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check React Native version in package.json
echo "=== React Native Version ==="
if [ -f "package.json" ]; then
rg '"react-native":\s*"[^"]*"' package.json -o
else
echo "package.json not found"
fi
# Check for Android-related configuration
echo -e "\n=== Android Configuration Files ==="
fd -e gradle . --max-depth 3 | head -20Repository: RocketChat/Rocket.Chat.ReactNative
Length of output: 238
🌐 Web query:
Android SDK 36 release status and stability January 2026
💡 Result:
Short answer: As of January 4, 2026, Android SDK 36 (Android 16 / "Baklava") is a stable, production SDK (Platform Stability reached; SDK Platform Revision 1 released). Google continues to ship quarterly minor updates (QPRs) and beta builds (QPR1–QPR3 betas/QPR images) but API 36 is stable for targeting and production use; developers should test against the latest QPR/beta images for device-specific fixes and large‑screen behavior changes. [1][2][3]
Sources
- SDK platform/revision and stability notes (Android Studio / SDK Platforms). [1]
- Android 16 release notes and QPR beta timeline. [2]
- Android Developers blog summary of app-impacting behavior changes for Android 16 (targeting/API expectations and opt‑outs for large screens). [3]
🌐 Web query:
Kotlin 2.1.20 release status and compatibility with React Native
💡 Result:
Short answer
- Kotlin 2.1.20 is a released tooling update (released March 20, 2025). [1][2]
- React Native itself has no single enforced Kotlin runtime version; compatibility depends on the Android native modules you use (many RN modules and Compose-related libraries enforce or expect specific Kotlin/Compose-compiler metadata), so moving to 2.1.20 can work but may break some native dependencies until those libraries are updated. Common workarounds are pinning a Kotlin version in android/build.gradle or waiting/upgrading native modules that require newer Kotlin. Test your app and native modules after upgrading. [1][2][3][4]
Sources
- Kotlin 2.1.20 “What’s new” and releases. [1][2]
- Examples of React Native Android module issues caused by Kotlin-version mismatches (GitHub/issues and community threads). [3][4]
🌐 Web query:
React Native 0.81 Android SDK 36 compileSdkVersion compatibility requirements
💡 Result:
Short answer
- React Native 0.81 defaults to targeting Android 16 (API level 36). Set targetSdkVersion = 36. [1]
- Your project must compile against API 36 (compileSdkVersion >= 36) if you use libraries that require API 36. [1][2]
- To compile with API 36 you must use an Android Gradle Plugin that supports API 36 (AGP 8.10+ / AGP releases that list API 36 support) and a compatible Gradle/JDK per AGP docs. Install Android SDK Platform 36 in SDK Manager. [2][3]
Practical checklist
- android/app/build.gradle (or build.gradle.kts): set compileSdk = 36 and targetSdk = 36. [1]
- Upgrade AGP to a version that supports API 36 (e.g. AGP 8.10+), and upgrade Gradle/JDK to the versions AGP requires. [2][3]
- In Android Studio SDK Manager install "Android API 36 (Android 16)" platform. [1][2]
- Rebuild and test for Android‑16 behavior changes (edge-to-edge, back gesture, SafeAreaView deprecation). [1]
Sources
- React Native 0.81 release notes (Android 16 / API 36 defaults). [1]
- Android Gradle Plugin 8.10.0 compatibility (supports API 36). [2]
- Android Developers AGP/API-level compatibility table. [3]
Verify Kotlin 2.1.20 compatibility with third-party native modules before merging.
Android SDK 36 with compileSdkVersion and targetSdkVersion 36 is officially required and stable for React Native 0.81. However, Kotlin 2.1.20 may break native module dependencies—many Android libraries and React Native modules have not yet been updated to support this version. Before proceeding, test your build and native modules with Kotlin 2.1.20, or pin an earlier Kotlin version in android/build.gradle until dependent libraries are updated.
🤖 Prompt for AI Agents
In android/build.gradle around lines 3 to 8, Kotlin is set to 2.1.20 which may
break third-party native modules; either validate compatibility by building the
app and running all native-module integration tests (clean build,
assembleRelease/Debug, and run on devices/emulators) and fix any module
compilation errors, or pin kotlinVersion to a proven-compatible release (for RN
0.81 ecosystems prefer e.g. 1.8.22) until dependents are updated; if pinning,
change kotlinVersion in this file to the chosen version and re-run Gradle sync
and full builds to confirm all native modules compile.
| distributionBase=GRADLE_USER_HOME | ||
| distributionPath=wrapper/dists | ||
| distributionUrl=https\://services.gradle.org/distributions/gradle-8.13-bin.zip | ||
| distributionUrl=https\://services.gradle.org/distributions/gradle-8.14.3-bin.zip |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Gradle 8.14.3 compatibility Android SDK 36
💡 Result:
Short answer: Yes — Gradle 8.14.3 can be used with Android API/SDK 36, provided you use a compatible Android Gradle Plugin (AGP) release (AGP 8.13.x is the AGP line that documents support for API level 36). Update the Gradle wrapper to 8.14.3 and use AGP 8.13.x (or a later AGP that lists API 36 support). [1][2]
References:
- Gradle 8.14.3 release notes (upgrade the wrapper to 8.14.3). [1]
- Android Gradle Plugin compatibility / notes (AGP 8.13 supports maximum API level 36 and pairs with Gradle 8.13+). [2]
🌐 Web query:
Gradle 8.14.3 Kotlin 2.1.20 compatibility
💡 Result:
Short answer: Kotlin 2.1.20 is not officially supported on Gradle 8.14.3. Kotlin 2.1.20’s documented “fully supported” Gradle range ends at ~8.12.1, so Gradle 8.14.3 is newer than the officially supported maximum — it may work, but you can encounter deprecation warnings or breakage. [1][2]
Recommendation: upgrade the Kotlin Gradle plugin to a 2.2.x (or later) KGP that lists Gradle 8.14 as supported (e.g., 2.2.20+ / 2.3.0 for fuller support), or use a Gradle version ≤ 8.12.1 if you must stay on Kotlin 2.1.20. [2][3]
Sources:
- Kotlin 2.1.20 release notes (states full support through Gradle 8.11 and notes about newer Gradle possibly producing warnings). [1]
- Kotlin Gradle plugin compatibility table (shows KGP 2.1.20–2.1.21 fully supported on Gradle 7.6.3–8.12.1). [2]
- Gradle compatibility / Kotlin guidance (shows which Gradle / Kotlin ranges are tested; use newer KGP for Gradle 8.14). [3]
Gradle 8.14.3 requires Kotlin 2.2.x or later — current Kotlin 2.1.20 is not officially supported.
Gradle 8.14.3 is compatible with Android SDK 36 when using AGP 8.13.x or later. However, Kotlin 2.1.20 is only officially supported up to Gradle 8.12.1; using it with Gradle 8.14.3 may produce deprecation warnings or build failures. Either upgrade Kotlin to 2.2.x+ (which supports Gradle 8.14) or downgrade Gradle to 8.12.1 if staying on Kotlin 2.1.20.
🤖 Prompt for AI Agents
In android/gradle/wrapper/gradle-wrapper.properties around line 3, the project
currently pins Gradle to 8.14.3 which is incompatible with Kotlin 2.1.20; either
upgrade the Kotlin plugin to 2.2.x or later or change the distributionUrl to a
Gradle version supported by Kotlin 2.1.20 (e.g., 8.12.1). To fix, choose one: A)
update the Kotlin version in your Gradle settings/build.gradle(.kts) to 2.2.x+
(bump the kotlin plugin and any Kotlin stdlib/native deps) and rebuild; or B)
edit distributionUrl in this file to use
https://services.gradle.org/distributions/gradle-8.12.1-bin.zip to remain on
Kotlin 2.1.20. Ensure you run a clean build after making the change and update
any CI config that pins Gradle or Kotlin versions.
| <key>RCTNewArchEnabled</key> | ||
| <true/> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check for native iOS modules that might need new architecture updates
echo "=== Checking for native iOS modules (*.mm and *.m files) ==="
find ios/ -type f \( -name "*.mm" -o -name "*.m" \) 2>/dev/null | head -30
echo -e "\n=== Checking for RCT references in native files ==="
find ios/ -type f \( -name "*.mm" -o -name "*.m" \) -exec grep -l "RCT" {} \; 2>/dev/null | head -20
echo -e "\n=== Checking for react-native dependencies in package.json ==="
if [ -f package.json ]; then
cat package.json | jq '.dependencies, .devDependencies' 2>/dev/null | grep -i "react"
fi
echo -e "\n=== Checking for newArchEnabled or fabric mentions in codebase ==="
rg "newArchEnabled|fabric|TurboModule" --type plist --type json . 2>/dev/null | head -20Repository: RocketChat/Rocket.Chat.ReactNative
Length of output: 4112
🏁 Script executed:
#!/bin/bash
# Check the current Info.plist to understand full context
echo "=== Examining Info.plist for React Native settings ==="
if [ -f "ios/RocketChatRN/Info.plist" ]; then
wc -l ios/RocketChatRN/Info.plist
sed -n '70,85p' ios/RocketChatRN/Info.plist
fi
echo -e "\n=== Checking for Podfile or other React Native configuration ==="
if [ -f "ios/Podfile" ]; then
echo "Podfile exists, checking for post_install hooks:"
grep -A 5 "post_install" ios/Podfile | head -20
fiRepository: RocketChat/Rocket.Chat.ReactNative
Length of output: 1118
🏁 Script executed:
#!/bin/bash
# Check for native module declarations in Android or Podspec files
echo "=== Checking for native modules in Podspec files ==="
find ios/ -name "*.podspec" -type f -exec head -30 {} + 2>/dev/null
echo -e "\n=== Checking package.json for versions and native modules ==="
if [ -f package.json ]; then
echo "React Native version:"
jq '.dependencies["react-native"], .devDependencies["react-native"]' package.json
echo -e "\nNative module dependencies:"
jq '.dependencies | to_entries[] | select(.value | contains("native") or contains("react-native")) | .key' package.json 2>/dev/null
fiRepository: RocketChat/Rocket.Chat.ReactNative
Length of output: 336
Major change: React Native New Architecture enabled.
Setting RCTNewArchEnabled to true enables React Native's new architecture (Fabric renderer, TurboModules). This is a significant architectural change requiring thorough testing.
Several custom native modules exist that need verification for new architecture compatibility:
- A11yFlowModule and AppGroup modules (contain RCT references)
- SSLPinning and SecureStorage modules (security-critical; require careful testing)
- MMKV storage utilities
Additionally, verify compatibility of the forked react-native-image-crop-picker dependency with the new architecture. Most core dependencies (react-native-reanimated, react-native-gesture-handler, react-native-screens, @react-native-firebase) have new architecture support in their current versions.
Conduct comprehensive testing of all components, especially native modules and security-critical features, before merging.
🤖 Prompt for AI Agents
In ios/RocketChatRN/Info.plist around lines 75-76, RCTNewArchEnabled is set to
true enabling React Native's new architecture; you must verify and update all
native modules for compatibility: inspect A11yFlowModule and AppGroup for direct
RCT references and migrate them to TurboModule/Fabric-compatible APIs or update
their bridging code, validate SSLPinning and SecureStorage native
implementations for thread-safety and new JS-native bindings, ensure MMKV
integration uses the new-arch-compatible native API or update to a supported
version, confirm the forked react-native-image-crop-picker is updated for
TurboModules/Fabric or replace it, update iOS project registration (Podfile,
module registry, and any RCT_EXTERN/RCT_EXPORT macros) as needed, run a clean
iOS build with RCT_NEW_ARCH_ENABLED=1, execute full integration and security
tests on device/simulator, and only merge after all modules build and pass
tests.
| <key>bugsnag</key> | ||
| <dict> | ||
| <key>apiKey</key> | ||
| <string>apiKeyValue</string> | ||
| </dict> |
There was a problem hiding this comment.
Replace placeholder Bugsnag API key.
The Bugsnag apiKey is set to the placeholder value "apiKeyValue". This must be replaced with the actual Bugsnag API key before deployment, otherwise crash reporting will not function.
Consider using environment variables or build-time substitution to inject the actual API key:
<string>$(BUGSNAG_API_KEY)</string>Then define BUGSNAG_API_KEY in your build configuration or CI/CD pipeline.
🤖 Prompt for AI Agents
In ios/RocketChatRN/Info.plist around lines 108 to 112 the Bugsnag apiKey is set
to the placeholder "apiKeyValue"; replace this with the real Bugsnag API key or
implement build-time injection (e.g., swap the string for a build variable like
$(BUGSNAG_API_KEY) and ensure BUGSNAG_API_KEY is defined in the Xcode build
settings or CI/CD secrets) so crash reporting receives the actual key.
| <key>bugsnag</key> | ||
| <dict> | ||
| <key>apiKey</key> | ||
| <string>apiKeyValue</string> | ||
| </dict> |
There was a problem hiding this comment.
Replace placeholder Bugsnag API key in Share extension.
The Bugsnag apiKey is set to "apiKeyValue" placeholder. This must be replaced with the actual API key for crash reporting to function in the Share extension.
Consider using the same environment variable approach as the main app:
<string>$(BUGSNAG_API_KEY)</string>🤖 Prompt for AI Agents
In ios/ShareRocketChatRN/Info.plist around lines 72 to 76, the Bugsnag apiKey is
currently a placeholder ("apiKeyValue"); replace it with the real API key by
switching to the environment variable approach used by the main app, e.g. set
the <string> to the build-time variable for Bugsnag ($(BUGSNAG_API_KEY)) so the
Share extension receives the correct key at build time; ensure the build config
or CI provides BUGSNAG_API_KEY for the extension target.
| "react-dom": "19.1.0", | ||
| "react-native-dotenv": "3.4.8", | ||
| "storybook": "9.0.9", | ||
| "typescript": "5.4.3" |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
TypeScript 5.8.3 breaking changes from 5.4.3
💡 Result:
Here are the main breaking / behavior-changing items introduced between TypeScript 5.4.x and 5.8.x that are most likely to affect existing code when upgrading from 5.4.3 to 5.8.3. Check the linked release-note pages for examples and migration notes.
-
lib.d.ts / DOM type updates — updates to built-in libs (DOM, lib.d.ts) across releases can change inferred types and cause new errors. Expect this to be a common source of regressions. [1][2][3][4][5]
-
More-accurate conditional-type constraints / stricter conditional checking — conditional/generic types are checked more precisely, which can make previously-accepted code fail (e.g., conditional type assignability and inference changes). [2]
-
Granular checks for branches in return expressions — each branch of conditional return expressions is checked more strictly against a function’s declared return type (can surface new errors). (5.8). [5]
-
Checks for super property access / class-field-related errors — accesses like super.x where x is a class field are more strictly diagnosed. (landed earlier and continued to be enforced). [2]
-
Never-initialized-variable checks — improved analysis can catch uses-before-assignment in more cases (can produce new errors). (5.7). [4]
-
TypedArrays generic change — TypedArray types (Uint8Array, etc.) became generic over ArrayBufferLike which can change some signatures. (5.7). [4]
-
More implicit-any errors for some function returns — in some contexts (e.g., functions returning null/undefined and generic contextual typing) implicit any errors are now reported where they weren’t before. (5.7). [4]
-
Module resolution / ESM interop changes — improvements to Node/ESM interoperability (notably nodenext behaviors and validated JSON imports) and related module-resolution refinements may change import resolution/typing. Test module boundaries after upgrading. (5.6–5.8). [3][5][4]
-
--build and emit behavior changes — build mode now continues past intermediate project errors by default (new --stopOnBuildErrors to restore prior behavior) and .tsbuildinfo handling changed. This can change CI/build outputs. (5.6). [3]
-
New compiler flags/features that affect emit/checking semantics — examples: --noCheck (skip semantic checking, 5.6), --erasableSyntaxOnly and lib-replacement features (5.8); using or not expecting these flags can change behavior. [3][5]
Notes:
- The “lib.d.ts / DOM” notes appear in multiple release pages and are the single most frequent source of upgrade breakage — inspect your usages of DOM/ambient types. [1][2][4][5]
- For each release (5.5, 5.6, 5.7, 5.8) consult the full release notes linked below for concrete examples and suggested fixes.
Sources:
[1] TypeScript 5.4 release notes (breaking/conditional-type and lib.d.ts notes).
[2] TypeScript 5.5 release notes.
[3] TypeScript 5.6 release notes.
[4] TypeScript 5.7 release notes.
[5] TypeScript 5.8 release notes.
If you want, I can:
- produce a prioritized checklist of what to search for in your codebase (imports, conditional types, return branches, class super accesses, TypedArray uses), or
- scan a small file or code sample against the specific errors you see after upgrading and explain fixes.
Update TypeScript to 5.8.3 — be aware of breaking changes between 5.4.3 and 5.8.3.
This upgrade includes several behavior-changing improvements that may affect the codebase:
- lib.d.ts / DOM type updates (most common source of regressions) — review DOM and ambient type usage
- More-accurate conditional-type constraints and stricter return-branch checking
- Improved never-initialized-variable detection — may surface new errors
- Module resolution and ESM interop refinements — test module boundaries
- TypedArray generics and implicit-any error improvements
Run type-checking and tests thoroughly after upgrading to catch any regressions. Prioritize reviewing DOM type usage and return type declarations.
🤖 Prompt for AI Agents
In package.json at line 208 update the TypeScript version from 5.4.3 to 5.8.3
and then run a full install and CI-typecheck/tests; after upgrading, run tsc and
the test suite to surface regressions, review failures and fix them by (1)
updating tsconfig.lib/tsconfig.json "lib" entries if DOM/ambient type changes
cause conflicts, (2) correcting stricter return-branch and conditional-type
errors by adding explicit return types or narrowing logic, (3) fixing
never-initialized-variable errors by initializing or typing variables, and (4)
addressing module resolution/ESM interop changes by adjusting
moduleResolution/esModuleInterop settings or import/export syntax; iterate until
typecheck and tests pass.
Proposed changes
Depends on:
#6720
#6729
Pending:
Update typescript to version 5.8.3
Issue(s)
Closes #6874
Closes #6803
How to test or reproduce
Screenshots
Types of changes
Checklist
Further comments
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.