fix(swiftpm): actually read the artifacts version pin back - #57762
Open
chrfalch wants to merge 1 commit into
Open
fix(swiftpm): actually read the artifacts version pin back#57762chrfalch wants to merge 1 commit into
chrfalch wants to merge 1 commit into
Conversation
`spm add --version <ver>` / `spm update --version <ver>` already wrote an
`artifactsVersionOverride` into the `.spm-injected.json` marker, and
`readArtifactsVersionOverride` already existed to read it back — but nothing
ever called it. Only the write half was wired; every reference to the reader
was a test.
The sole resolver, determineVersion, went straight from the `--version` flag to
node_modules/react-native/package.json. So after `spm add --version X`, a later
flagless `spm update` silently re-pointed the project at package.json's version
instead, while the marker went on claiming X. `--version` was effectively
single-use. In this monorepo package.json is 1000.0.0, which has no published
artifacts, so a flagless run after a pinned add fails outright — hence the
standing advice to pass `--version` on every invocation.
Insert the pin between the two existing sources:
--version -> pinned override -> react-native/package.json
`spm download` and the scaffold path pick it up for free, since both use the
same resolved value. Since this is persistent state, log one line when the pin
is the source, so a stale pin is diagnosable rather than silent; there is still
no way to clear it short of `deinit`.
Three comments claimed the build-time sync read this override via
readArtifactsVersionOverride. It does not, and never did — the sync action
returns before artifacts are resolved at all. They now name the real consumer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
chrfalch
requested review from
cipolleschi and
Copilot
and removed request for
Copilot
July 30, 2026 09:04
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
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:
spm add --version <ver>pinned a value that nothing ever read back.The marker write has been there all along, and so has the reader —
readArtifactsVersionOverride()inspm/generate-spm-xcodeproj.js, exported and unit-tested. It just had zero production callers. Every reference to it was a test.determineVersion— the only resolver — went straight from the flag topackage.json:That value picks which artifact slots the project gets wired to. So:
spm add --version 0.88.0-nightly-…→ wires the nightly's slots, pins the label ✅spm update(no flag) → silently resolvespackage.json's version instead, re-pointing the project at different slots, while the marker still claims the nightly ❌--versionwas effectively single-use. In this monorepopackage.jsonis1000.0.0, which has no published artifacts, so a flagless run after a pinnedaddfails outright — which is why the standing advice has been to pass--versionon every invocation. That advice was working around this bug.Fix: insert the pin between the two existing sources.
15 lines of logic.
spm downloadand the scaffold path pick it up for free, since both consume the same resolved value. Because this is persistent state, one line is logged when the pin is the source, so a stale pin is diagnosable instead of silent; there is still no way to clear it short ofdeinit.Three comments were actively wrong and are corrected here: the reader's doc block, the marker-field comment, and
findInjectedXcodeproj's comment all asserted that the build-time sync calls this viareadArtifactsVersionOverride. It does not and never did — thesyncaction returns before artifacts are resolved at all. Those comments are what made the gap invisible; they misled me while investigating.Changelog:
[Internal] [Fixed] - SwiftPM:
spm --versionnow sticks, so a later run without the flag keeps using the pinned artifact versionTest Plan:
yarn jest packages/react-native/scripts→ 31 suites, 684 tests, all green.New tests, written red first — the load-bearing one failed with
Expected: "0.80.0" / Received: "1000.0.0", i.e. exactly the reported bug:--versiongiven → wins, even with a different value pinnedpackage.json's version (unchanged behaviour)package.json's version, no throwThe three fallback cases passed before the fix too, which is the point — they pin today's behaviour so this change can't regress it.
Note on landing order
Touches
setup-apple-spm.jsandspm/generate-spm-xcodeproj.js, which #57744, #57756 and #57757 also touch. All are cut independently frommain; whichever lands first, I'll rebase the rest. #57756 is the closest relative — it does the same wiring for--config-command, which had the identical write-only-pin shape.