Uh oh!
There was an error while loading. Please reload this page.
[iOS][swiftpm] Resolve SwiftPM manifest naming collisions - #58044
Open
chrfalch wants to merge 1 commit into
Open
[iOS][swiftpm] Resolve SwiftPM manifest naming collisions#58044chrfalch wants to merge 1 commit into
chrfalch wants to merge 1 commit into
Conversation
chrfalchforce-pushed
the
spm/name-constants
branch
from
August 21, 2026 09:40
380b803 to
c2fb471Comparechrfalchforce-pushed
the
spm/reserved-name-guard
branch
from
August 21, 2026 09:42
232df94 to
c9aa6aeComparechrfalchforce-pushed
the
spm/reserved-name-guard
branch
from
August 24, 2026 09:08
c9aa6ae to
b8cc821Comparecipolleschi
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. |
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>
chrfalchforce-pushed
the
spm/reserved-name-guard
branch
from
August 24, 2026 13:45
b8cc821 to
881411aCompare
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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