`package:ios --add-spm-package`: allow project-declared extra XCFrameworks as binary targets

オープン
#468 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
55/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
swift, typescript

調査の方向性

Start with createLocalSpmPackage.ts and schema.json, then trace how package:ios reads the iOS configuration and resolves reserved XCFramework names. Confirm the default configuration preserves current output, while configured entries are validated, copied into spm-artifacts/, emitted as binary targets, and included in the library product without changing BrownfieldLib, Podfiles, or Xcode projects.

索引モデルが issue の本文から書いたものです。

説明

Summary

brownfield package:ios --add-spm-package generates a local Swift package whose binary targets are fixed: the app framework, Hermes, ReactBrownfield, Brownie/BrownfieldNavigation, and the Expo support list in emitExpoSupportXcframeworks.ts. There is no way for a project to declare an additional XCFramework that the host must import directly.

Problem

Some Swift modules cannot be fused into the packaged RN framework: the host app has to link and import them itself (the same reason ExpoModulesCore is shipped as a separate XCFramework instead of inside BrownfieldLib). Today the host ends up with two integration paths: the generated SPM package for RN, plus a hand-added local Swift package or a manually dragged XCFramework for the extra module. --add-spm-package promises “one Add Local”; that promise breaks as soon as a project has one such module.

Dropping an extra *.xcframework into the package dir is not a workaround: createLocalSpmPackage.resolveAppFrameworkName treats any non-reserved XCFramework as an app-framework candidate, so without --scheme it either fails with “multiple candidates” or picks the wrong one.

Proposal (opt-in, additive)

// brownfield.config.js
module.exports = {
  ios: {
    extraSpmXcframeworks: [
      { name: 'MyHostModule', path: './artifacts/MyHostModule.xcframework' },
    ],
  },
};
  • Default [] → byte-identical to current behavior.
  • Only consumed when --add-spm-package is set.
  • Each name is added to RESERVED_FRAMEWORK_NAMES for that run, so it never competes with app-framework resolution.
  • Copied into spm-artifacts/ with normalizeCopiedXcframework, emitted as one more .binaryTarget and listed in the library product.
  • Not linked into BrownfieldLib; no Podfile or Xcode project changes.
  • Missing path → hard error naming the entry. No silent skip.
  • Schema: BrownfieldIosConfig.extraSpmXcframeworks (array of { name, path }), same shape family as extraParams.

Why here and not in the consumer

The host has no Node toolchain; the point of package:ios is that the RN side owns packaging. A per-project list keeps that contract instead of pushing a second package onto every host.

Context

Hit this with a C++-free Swift API that must live beside (not inside) the RN framework so the host can provide() native implementations before startReactNative. Any analytics / design-system / internal SDK the host must import has the same shape.

Happy to send a PR against createLocalSpmPackage.ts + schema.json if the direction is acceptable.

主要言語
TypeScript
スター
549
フォーク
52
平均マージ
4日 19時間
マージ済み PR(30日)
3

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

callstack/react-native-brownfield のほかの issue

callstack/react-native-brownfield の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。