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

Đang mở
#468 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
swift, typescript
Lĩnh vực
build-system, cli, mobile

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
549
Fork
52
Merge trung bình
4 ngày 19 giờ
Pull request đã merge (30 ngày)
3

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của callstack/react-native-brownfield

Tất cả issue của callstack/react-native-brownfield

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.