Repository navigation
ci: build the react-native range's floor and latest weekly - #57
Merged
Merged
Conversation
The podspec requires iOS 17 (Object Capture's floor) and Expo SDK 57's template targets 16.4, so a clean pod install after prebuild refused the pod with 'required a higher minimum deployment target'. The plugin now sets ios.deploymentTarget in Podfile.properties.json, and only ever raises it, so an app already targeting higher keeps its value.
The React Native template targets iOS 15.1 and the pod requires 17, so following the install section as written failed at pod install on every current template.
react-native 0.79 peers on react ^19.0.0, so '>=18.2.0' admitted a combination npm rejects anyway. Moving the floor excludes nobody.
peerDependencies promises >=0.79 and PR CI only builds the example's 0.83. A new RN release breaks us on RN's schedule, not ours, and a docs or JS PR can't change which versions build, so this runs weekly, not per PR. It builds a stock template app with the packed library, the way a consumer installs it, since the example pins dependencies to its own RN line. Both ends pass today (0.79.7, 0.87.1). Closes #40
The 0.79 template pins xcodeproj < 1.26, which holds CocoaPods at 1.15.2, and that still requires kconv from nkf, which Ruby 3.4 (the macOS runner's) no longer ships by default. 0.87's template already lists it.
tristanheilman
force-pushed
the
ci/40-rn-compat
branch
from
October 10, 2026 00:50
c197fc5 to
6d84718
Compare
Skipping it on a hit left ios/build/generated missing: pod install is also where codegen writes ReactAppDependencyProvider, which isn't in the cache and depends on src/specs. The build's own pod install then failed with 'No podspec found'. This never showed before #56 because the cache had never been saved; it bit on this PR's second push.
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.
Closes #40.
What this does
peerDependenciespromisesreact-native >=0.79, but PR CI only ever built the example's 0.83. The newrn-compat.ymlbuilds both ends of that promise weekly (Mondays, plus a manual run button that takes any list of versions):peerDependencies. It's read frompackage.json, so moving the range moves what gets built.latest: whatever npm says at run time, so the check can't go stale the way the range did.Each one is a stock template app with the library installed from
npm pack, the way a consumer gets it. The example app can't simply swap versions, becausereact-native-screensand others are pinned to its own React Native line..github/scripts/rn-compat-app.shtypechecks and bundles a screen that uses the public API, then compiles for generic iOS without signing.Weekly rather than per PR: a new React Native release breaks us on its own schedule, and a docs or JS PR can't change which versions build. PR CI is unchanged. The workflow also runs on PRs that touch the workflow or the script, so this PR runs it.
What it measured (locally, Xcode 26.6, Node 24)
react-native >=0.79.0is true and stays.reactmoves>=18.2.0→>=19.0.0. React Native 0.79 itself requiresreact ^19.0.0, so the old floor admitted a combination npm rejects anyway. Nobody is excluded.gem 'nkf', which 0.87's template already adds. And on Xcode 26: fmt 11.0.2, which React Native ≤ 0.82 ships, fails clang's consteval check inside React Native's own pods. The script compiles the fmt pod as C++17 when fmt is older than 11.1. Anyone on 0.79 with current Xcode already has this, or their app doesn't build.Found along the way, fixed here
Following the README's install failed
pod installon every current template, withrequired a higher minimum deployment target. The podspec requires iOS 17, but React Native's template targets 15.1 and Expo SDK 57's targets 16.4.platform :ios, '17.0'line.ios.deploymentTargetinPodfile.properties.jsonto 17.0, and never lowers it. Unit tests are included. Verified with a real SDK 57expo prebuildand a cleanpod install. A control run at 16.4 fails, but only after deletingPodfile.lock: a lockfile that already resolved the pod hides the error.Merging
Rebase-merge. release-please only turns
featandfixcommits into changelog lines, so rebase gives the plugin fix and the React floor one line each. Squash would collapse everything under thisci:title, and both user-facing fixes would vanish from the changelog.