[iOS][swiftpm] Resolve SwiftPM manifest naming collisions - #58044
Closed
chrfalch wants to merge 1 commit into
Closed
[iOS][swiftpm] Resolve SwiftPM manifest naming collisions#58044chrfalch wants to merge 1 commit into
chrfalch wants to merge 1 commit into
Conversation
chrfalch
changed the title
meta-cla
Bot
added
the
CLA Signed
chrfalch
force-pushed
the
spm/name-constants
branch
from
August 21, 2026 09:40
380b803 to
c2fb471
Compare
chrfalch
force-pushed
the
spm/reserved-name-guard
branch
from
August 21, 2026 09:42
232df94 to
c9aa6ae
Compare
chrfalch
force-pushed
the
spm/reserved-name-guard
branch
from
August 24, 2026 09:08
c9aa6ae to
b8cc821
Compare
facebook-github-tools
Bot
added
the
Shared with Meta
cipolleschi
approved these changes
Aug 24, 2026
cipolleschi
approved these changes
Aug 24, 2026
|
@cipolleschi has imported this pull request. If you are a Meta employee, you can view this in D117178818. |
chrfalch
force-pushed
the
spm/reserved-name-guard
branch
from
August 24, 2026 13:45
b8cc821 to
881411a
Compare
A dependency's Swift name is derived from its npm package name with the scope dropped, which makes two collisions unavoidable: `@powersync/react-native` derives `ReactNative`, one of React Native's own names, and `@a/foo` and `@b/foo` both derive `Foo`. Either was emitted into the package graph as-is, and SwiftPM then failed deep inside dependency resolution with a duplicate-name error that named neither the library nor the react-native.config.js that caused it. The scope that was dropped is the fix. A scoped dep whose derived name is reserved gets the TitleCased scope prepended (`PowersyncReactNative`), and deps that resolved to the same name get it prepended too (`AFoo`, `BFoo`), so the library author has nothing to do. Every disambiguation logs one line naming the package, the name it would have taken and the name it got. Nothing can regress on this — both collisions fail SwiftPM resolution today, so no working library carries such a name and no consumer imports headers under it. The two cases need different shapes. A reserved name is decidable per dep, so it resolves in `resolveSwiftName`. A collision with another dep is not visible from there, so it is a pass over the resolved set: group by name, and prepend the scope to every scoped member of a group larger than one. Every member moves rather than one arbitrary winner staying put, since there is no non-arbitrary winner. Two members never move: a name the author set with `spm.name` (their choice wins, and the others move around it) and an unscoped one (no scope to borrow). The pass runs once, and then the whole set is validated — this is the part that has to be right. A borrowed scope can land on a name another dep already holds (`@a/foo` → `AFoo`, next to a package `a-foo`) or on a reserved one, and two libraries silently sharing a name is worse than the error this replaces. So both existing checks now run over the final set, and anything a scope could not resolve still fails with the message it did before: two unscoped deps deriving the same name, an explicit `spm.name` that is reserved, a group whose only scoped member's new name is taken. Retrying instead of failing would trade a diagnosable error for a name nobody can predict. Reserving the names React Native puts in a manifest is what makes the first case diagnosable at all. Matching is case-insensitive throughout: a name that differs from another only in case is not distinct enough for the build to keep the two apart. The reserved check runs before the dep-vs-dep one, so the more specific diagnosis wins, and it runs for a library that ships an autolinking plugin too: `spm scaffold` knows nothing about plugins, so an exemption there would leave the two commands disagreeing about the same library. `SpmNameCollisionError` distinguishes a misconfiguration from a resolution failure, so `scaffoldAll` — which degrades to the direct deps when a transitive dep can't be found — still surfaces it instead of scaffolding manifests SPM will reject. Its remote package config moves out of the same try for the same reason. Every Swift name reaching a manifest now comes from that one resolved set: the autolinker's two `toSwiftName` fallbacks would have re-derived the pre-disambiguation name and emitted a reference nothing matches, so they are replaced by a required lookup that fails loudly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
chrfalch
force-pushed
the
spm/reserved-name-guard
branch
from
August 25, 2026 09:59
881411a to
3f937fb
Compare
cortinico
approved these changes
Aug 25, 2026
cortinico
left a comment
cortinico
left a comment
Contributor
There was a problem hiding this comment.
Review automatically exported from Phabricator review in Meta.
meta-codesync Bot
pushed a commit
that referenced
this pull request
Aug 25, 2026
) Summary: An app declares extra native modules through spm.modules in its react-native.config.js. Those names went into the generated package graph unvalidated, and two of the ways they can go wrong fail silently. This PR fixes this by using the same Swift name collision detection/resolving as we introduced in #58044 > **NOTE:** #58044 must be merged before this one so that we can change the base branch for this one to `main` ## Changelog: [IOS] [FIXED] - Reject colliding or invalid spm.modules names instead of silently dropping a module from the build Pull Request resolved: #58060 Test Plan: ✅ Unit tests/CI Reviewed By: mdvacca Differential Revision: D117360298 Pulled By: cipolleschi fbshipit-source-id: d2531d51b6d371cf6bc98dc85c9071ee81fb7a37
|
@cipolleschi merged this pull request in 962aeec. |
cipolleschi
pushed a commit
that referenced
this pull request
Aug 26, 2026
Summary: A dependency's Swift name is derived from its npm package name with the scope dropped, which makes two collisions unavoidable: `powersync/react-native` derives `ReactNative`, one of React Native's own names, and `a/foo` and `b/foo` both derive `Foo`. Either was emitted into the package graph as-is, and SwiftPM then failed deep inside dependency resolution with a duplicate-name error that named neither the library nor the react-native.config.js that caused it. This was seen in the PR here powersync-ja/powersync-js#1076 - and was hard to fix. This PR fixes this by adding support for prefixing the name with the scope if the name without scope crashes. In addition the same logic is added when two packages have names that collide with each other. If the name given by the SwiftPM scaffolder doesn't work for you - you can use the `spm.name` field in the `react-native.config.js` file to set a specific name (see SwiftPM docs). [IOS] [FIXED] - Resolve Swift manifest naming collisions Pull Request resolved: #58044 Test Plan: ✅ Unit tests green Reviewed By: mdvacca, cortinico Differential Revision: D117178818 Pulled By: cipolleschi fbshipit-source-id: 23269f4d959b84ac484be1911e8a863c74008ff9 (cherry picked from commit 962aeec)
cipolleschi
pushed a commit
that referenced
this pull request
Aug 26, 2026
) Summary: An app declares extra native modules through spm.modules in its react-native.config.js. Those names went into the generated package graph unvalidated, and two of the ways they can go wrong fail silently. This PR fixes this by using the same Swift name collision detection/resolving as we introduced in #58044 > **NOTE:** #58044 must be merged before this one so that we can change the base branch for this one to `main` ## Changelog: [IOS] [FIXED] - Reject colliding or invalid spm.modules names instead of silently dropping a module from the build Pull Request resolved: #58060 Test Plan: ✅ Unit tests/CI Reviewed By: mdvacca Differential Revision: D117360298 Pulled By: cipolleschi fbshipit-source-id: d2531d51b6d371cf6bc98dc85c9071ee81fb7a37 (cherry picked from commit 39cd1df)
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
3 participants
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
A dependency's Swift name is derived from its npm package name with the scope dropped, which makes two collisions unavoidable:
@powersync/react-nativederivesReactNative, one of React Native's own names, and@a/fooand@b/fooboth deriveFoo.Either was emitted into the package graph as-is, and SwiftPM then failed deep inside dependency resolution with a duplicate-name error that named neither the library nor the react-native.config.js that caused it.
This was seen in the PR here powersync-ja/powersync-js#1076 - and was hard to fix.
This PR fixes this by adding support for prefixing the name with the scope if the name without scope crashes.
In addition the same logic is added when two packages have names that collide with each other.
If the name given by the SwiftPM scaffolder doesn't work for you - you can use the
spm.namefield in thereact-native.config.jsfile to set a specific name (see SwiftPM docs).Changelog:
[IOS] [FIXED] - Resolve Swift manifest naming collisions
Test Plan:
✅ Unit tests green