[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.

[cipolleschi]

Thanks for tackling this naming mismatch. This currently changes the common test library from the npm-derived ReactNativeTestLibraryCommon to its podspec name, TestLibraryCommon, while TestLibraryApple.mm still imports <ReactNativeTestLibraryCommon/TestLibraryCommon.h>. Both test_ios_spm_rntester Debug and Release fail with that header not found. Could we update the fixture/import and add regression coverage so these end-to-end SPM builds pass?

[cipolleschi]

Thanks for adding the podspec fallback. This fast path also picks up a subspec's ss.header_dir as though it were the package-level value: the regex matches the trailing s.header_dir. For example, react-native-svg has s.name = 'RNSVG' and a nested ss.header_dir = 'rnsvg', so this resolves rnsvg even though the intended library name here is RNSVG; react-native-screens has the same shape. Could we make this scope-aware (or fall back to the pod name / explicit config) and cover these external-pod shapes in a regression test?

[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.