[iOS][swiftpm] Derive an SPM library's Swift name from its podspec

[chrfalch]

Summary:

An autolinked library's SwiftPM target name is also its header import prefix, so deriving it from the npm package name was wrong for most of the ecosystem (react-native-svg publishes RNSVG, not ReactNativeSvg) and wrong silently — no error, just headers nobody can import under the expected name.

How:

This PR reads the podspec file on scaffolding, and will use the name from the podspec if available. In addition it deprecates the react-native.config.js spm section in favor of the library's package.json file.

Configuration

A package's SwiftPM settings now live in swiftpmConfig in its package.json, following codegenConfig's conventions: name, dependencies, autolinkingPlugin and scaffold for a library, modules and denyPlugins for an app. The spm block in react-native.config.js is deprecated — still read, so nothing breaks, but it warns once per file and package.json wins field by field.

Resolving

A name resolves from swiftpmConfig.name, then the deprecated spm.name, then the podspec's header_dir or name, then the npm name. The podspec is thereby transitional rather than permanent: spm scaffold records the name it derived as swiftpmConfig.name in the library's package.json, so the next run needs no podspec to name it. It never overwrites a name the library already declares, never records a name guessed from the npm name, and reports what it did.

Failsafety

A prefix Swift cannot spell is normalized to the identifier SwiftPM would compile it as, with a warning. A reserved name or two deps landing on one name is a hard error naming swiftpmConfig.name as the fix; the scope-borrowing that auto-corrected collisions is removed, since a name the build invents is a name no #import can predict. Collision checks key on SwiftPM's c99 name, so react-native-svg and react_native_svg no longer pass and then compile as one module.

Implementation

Name resolution reads the two podspec fields it needs with the regex parser, so it adds no pod ipc spec spawn, and the full read is memoized on the resolved path so one run reads a podspec once across name resolution, header search paths and scaffolding.

rn-tester and the Apple test library move to the new location.

Changelog:

[IOS] [FIXED] - Read SwiftPM name from podspec and store in package.json when scaffolding

Test Plan:

✅ Unit tests

[cipolleschi]

Thank you for putting this together—the direction addresses a real gap. I’m requesting changes for the two concrete blockers called out inline: the current RNTester SwiftPM builds fail after the target-name change, and the fast podspec parsing can promote a subspec header_dir to the package name for external libraries. Once those are fixed with regression coverage, I’ll be happy to take another look.

[chrfalch]

Thank you for putting this together—the direction addresses a real gap. I’m requesting changes for the two concrete blockers called out inline: the current RNTester SwiftPM builds fail after the target-name change, and the fast podspec parsing can promote a subspec header_dir to the package name for external libraries. Once those are fixed with regression coverage, I’ll be happy to take another look.

Fixed - Good catch.

The fast path is now anchored to the root spec. A subspec's ss.header_dir can no longer name the library. s.name = 'RNSVG' with a nested ss.header_dir = 'rnsvg' resolves RNSVG. react-native-screens behaves the same.

If a value is declared but not readable, the fast path declines. pod ipc spec then resolves it.

Tests: "does not take a subspec's header_dir as the library's" and "keeps the spec's own module_name, not a subspec's".

[chrfalch]

Both blockers are fixed. A later review found a third.

Podspec module_name was ignored. react-native-maps sets s.name = "react-native-maps" and s.module_name = "ReactNativeMaps", with no header_dir. So it resolved to react-native-maps, and the module became react_native_maps. Every import ReactNativeMaps broke.

The order is now header_dir → module_name → pod name. This matches CocoaPods: module_name || c99(header_dir) || c99(name).

No CI job would have caught it. RNTester has only the two fixtures.

Two smaller fixes. Both fixtures declare swiftpmConfig.name, so spm scaffold no longer writes to tracked files. A podspec with no readable name now warns, because the fallback depends on CocoaPods being installed.

929 tests, 20 suites.

[cipolleschi]

Thank you for addressing the earlier feedback and restoring the SwiftPM end-to-end builds. I left two follow-up questions about the intended one-target treatment of subspecs and how that model should distinguish a module name from its header namespace.

[cipolleschi]

Thanks—the ss fix and regression coverage make the intended parent naming much clearer. One question about the flattening model: are all podspec subspecs intended to become one SwiftPM target named after the parent spec? If so, should identity fields from nested scopes always be ignored, independently of the block-variable spelling? getSpecStringField would still accept a nested s.header_dir when a subspec reuses do |s|, for example. Would it be worth covering or documenting that shape so a subspec cannot accidentally rename the parent target?

[chrfalch]

Fixed — it was a bug, not a doc gap. A subspec spelled do |s| did rename the parent (header_dir resolved to the child value); my earlier fix anchored on the receiver spelling, not on scope.

To your question: yes — all subspecs become one target named after the parent, and identity fields from a nested scope should always be ignored, whatever the block variable is called. A regex over flat text cannot see block scope, so the fast path now declines when a subspec re-binds s or spec, and pod ipc spec answers instead. The same guard covers the pure-JS path, otherwise the bug survives wherever CocoaPods is absent. Merge-intended fields (source globs, header mapping dirs, dependencies, search paths) are unchanged.

[cipolleschi]

Related question: how should we represent a pod whose module_name and header_dir intentionally differ? CocoaPods keeps those as separate concepts, while this single resolved name picks header_dir and never reaches module_name. One external example is react-native-bare-kit, which declares header_dir = "BareKit" and module_name = "react_native_bare_kit". If the parent becomes one SwiftPM target, should its target/module identity follow module_name while header_dir is handled as a header alias/search path, or should we explicitly reject this shape? I mainly want to ensure scaffolding does not persist one namespace as swiftpmConfig.name while silently losing the other.

[chrfalch]

Confirmed on your example: react-native-bare-kit declares header_dir = "BareKit" and module_name = "react_native_bare_kit". We resolve BareKit, while CocoaPods compiles the module as react_native_bare_kit.

One SwiftPM target cannot carry both, since its module name and header namespace are the same string. So header_dir wins deliberately — it is the prefix existing ObjC consumers write.

Rather than change the precedence, spm scaffold now prints the name it chose and where it came from, and when both keys are declared and differ, which value is not used and that swiftpmConfig.name overrides it. So nothing is dropped silently before the name is persisted, which was your main concern.

Treating header_dir as a header alias alongside a module_name identity is the fuller answer — I would rather do that separately than grow this PR. SwiftPM is Preview, so the contract stays cheap to change.