ci(0.83): run PR checks on merge branch too#3007
Merged
Merged
Conversation
Cherry-pick of react@faeef2b (react#56099). fmt 11.0.2 enables `consteval` on Apple clang ≥ 14 (which includes Xcode 26.4), but Xcode 26.4's stricter clang rejects consteval expressions in fmt's format-inl.h. fmt 12.1.0 fixes this. Changes: - `packages/react-native/third-party-podspecs/fmt.podspec`: 11.0.2 → 12.1.0 - `packages/react-native/third-party-podspecs/RCT-Folly.podspec": fmt dep 11.0.2 → 12.1.0 - `packages/react-native/gradle/libs.versions.toml`: 11.0.2 → 12.1.0 - `packages/rn-tester/Podfile.lock`: updated fmt version + checksum - `scripts/releases/ios-prebuild/configuration.js`: 11.0.2 → 12.1.0 RNTester macOS builds successfully on Xcode 26.4. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add the macOS-only BUILD_FROM_HERMES_COMMIT member to the
HermesEngineSourceTypes type annotation, and inline the
{stdio: 'inherit'} exec options so execSync type-checks (hoisting them
into a variable widened the type and broke the invariant stdio field).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
PressableProps is exact, so passing the deprecated keyboard props raises [incompatible-type] rather than [prop-missing]. Update the suppressions to the correct code so flow-check passes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The 0.83 merge pulled in upstream's imperative focus/blur methods (canBecomeFirstResponder, handleCommand:args:, focus, blur, becomeFirstResponder, resignFirstResponder) without a platform guard, duplicating the macOS-specific implementations already present in the TARGET_OS_OSX block and causing "duplicate declaration" errors on macOS. Guard the upstream block with #if !TARGET_OS_OSX so macOS keeps its own window-based focus handling. Also convert the merged-in SwiftUI-filter code (effectiveContentView, transferVisualPropertiesFromView, hit testing container, drop shadow color) from raw UIView/UIColor to the RCTPlatformView/RCTPlatformColor aliases so the translation unit compiles on macOS. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The npmPackageName assignment added in microsoft#2956 was not prettier-formatted. Now that PR checks run format-check on the merge branch, apply prettier so the check passes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Saadnajmi
force-pushed
the
ci-for-merge
branch
2 times, most recently
from
4208637 to
712b64f
Compare
tido64
reviewed
Jul 7, 2026
tido64
approved these changes
Jul 7, 2026
2 tasks
Saadnajmi
added a commit
to Saadnajmi/react-native-macos
that referenced
this pull request
Jul 7, 2026
PR microsoft#3006 moved the RCTSwiftUI platform types into the React_RCTUIKit Objective-C module via @compatibility_alias. That works for the Obj-C classes (RCTPlatformView -> UI/NSView, RCTPlatformColor -> UI/NSColor), which import into Swift fine, but it silently breaks for the SwiftUI types, so RCTSwiftUI-macOS fails to compile: RCTSwiftUIContainerView.swift: error: cannot find type 'RCTPlatformHostingController' in scope error: cannot find type 'RCTPlatformViewRepresentable' in scope error: cannot find type 'Context' in scope (x2) UI/NSHostingController and UI/NSViewRepresentable are Swift-only SwiftUI types (a generic class and a protocol). An Objective-C @compatibility_alias to them is not imported by Swift's Clang importer (and SwiftUI is not even imported in RCTUIKitCompat.h), so those two aliases resolve to nothing in Swift. The Context errors are secondary: once RCTPlatformViewRepresentable conformance is unknown, its associated Context type can't be resolved either. Fix (keeps microsoft#3006's intent of centralizing the platform types in React_RCTUIKit): - Add RCTUIKitCompat.swift to the React-RCTUIKit pod, declaring RCTPlatformHostingController and RCTPlatformViewRepresentable as Swift typealiases (guarded by #if os(macOS)). The pod now compiles Swift (SWIFT_VERSION) and links SwiftUI, so these types are exported to any module that does `import React_RCTUIKit`. - Remove the two non-functional SwiftUI @compatibility_alias entries from RCTUIKitCompat.h (nothing in Objective-C referenced them) and leave a note explaining why SwiftUI types must be declared in Swift. - Implement RCTPlatformViewWrapper with the concrete UI/NSViewRepresentable requirements (makeUIView/makeNSView + updateUIView/updateNSView); the previous makeRCTPlatformView/updateRCTPlatformView names did not satisfy either protocol. iOS behavior is unchanged (RCTPlatformHostingController -> UIHostingController, RCTPlatformViewRepresentable -> UIViewRepresentable). Validated locally with Xcode 26.4.1: a clean build of the RCTSwiftUI-macOS target and a full `RNTester-macOS` app build (arm64 + x86_64) both succeed. Note: the regressing PR microsoft#3006 merged just before microsoft#3007 ("ci(0.83): run PR checks on merge branch too"), so the merge-branch Build RNTester / macos job was not yet running when microsoft#3006 landed, which is why this compile break was not caught at merge time. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Saadnajmi
added a commit
to Saadnajmi/react-native-macos
that referenced
this pull request
Jul 7, 2026
PR microsoft#3006 moved the RCTSwiftUI platform types into the React_RCTUIKit Objective-C module via @compatibility_alias. That works for the Obj-C classes (RCTPlatformView -> UI/NSView, RCTPlatformColor -> UI/NSColor), which import into Swift fine, but it silently breaks for the SwiftUI types, so RCTSwiftUI-macOS fails to compile: RCTSwiftUIContainerView.swift: error: cannot find type 'RCTPlatformHostingController' in scope error: cannot find type 'RCTPlatformViewRepresentable' in scope error: cannot find type 'Context' in scope (x2) UI/NSHostingController and UI/NSViewRepresentable are Swift-only SwiftUI types (a generic class and a protocol). An Objective-C @compatibility_alias to them is not imported by Swift's Clang importer (and SwiftUI is not even imported in RCTUIKitCompat.h), so those two aliases resolve to nothing in Swift. The Context errors are secondary: once RCTPlatformViewRepresentable conformance is unknown, its associated Context type can't be resolved either. Fix (keeps microsoft#3006's intent of centralizing the platform types in React_RCTUIKit): - Add RCTUIKitCompat.swift to the React-RCTUIKit pod, declaring RCTPlatformHostingController and RCTPlatformViewRepresentable as Swift typealiases (guarded by #if os(macOS)). The pod now compiles Swift (SWIFT_VERSION) and links SwiftUI, so these types are exported to any module that does `import React_RCTUIKit`. - Remove the two non-functional SwiftUI @compatibility_alias entries from RCTUIKitCompat.h (nothing in Objective-C referenced them) and leave a note explaining why SwiftUI types must be declared in Swift. - Implement RCTPlatformViewWrapper with the concrete UI/NSViewRepresentable requirements (makeUIView/makeNSView + updateUIView/updateNSView); the previous makeRCTPlatformView/updateRCTPlatformView names did not satisfy either protocol. iOS behavior is unchanged (RCTPlatformHostingController -> UIHostingController, RCTPlatformViewRepresentable -> UIViewRepresentable). Validated locally with Xcode 26.4.1: a clean build of the RCTSwiftUI-macOS target and a full `RNTester-macOS` app build (arm64 + x86_64) both succeed. Note: the regressing PR microsoft#3006 merged just before microsoft#3007 ("ci(0.83): run PR checks on merge branch too"), so the merge-branch Build RNTester / macos job was not yet running when microsoft#3006 landed, which is why this compile break was not caught at merge time. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Saadnajmi
added a commit
to Saadnajmi/react-native-macos
that referenced
this pull request
Jul 7, 2026
PR microsoft#3006 moved the RCTSwiftUI platform types into the React_RCTUIKit Objective-C module via @compatibility_alias. That works for the Obj-C classes (RCTPlatformView -> UI/NSView, RCTPlatformColor -> UI/NSColor), which import into Swift fine, but it silently breaks for the SwiftUI types, so RCTSwiftUI-macOS fails to compile: RCTSwiftUIContainerView.swift: error: cannot find type 'RCTPlatformHostingController' in scope error: cannot find type 'RCTPlatformViewRepresentable' in scope error: cannot find type 'Context' in scope (x2) UI/NSHostingController and UI/NSViewRepresentable are Swift-only SwiftUI types (a generic class and a protocol). An Objective-C @compatibility_alias to them is not imported by Swift's Clang importer (and SwiftUI is not even imported in RCTUIKitCompat.h), so those two aliases resolve to nothing in Swift. The Context errors are secondary: once RCTPlatformViewRepresentable conformance is unknown, its associated Context type can't be resolved either. Fix (keeps microsoft#3006's intent of centralizing the platform types in React_RCTUIKit): - Add RCTUIKitCompat.swift to the React-RCTUIKit pod, declaring RCTPlatformHostingController and RCTPlatformViewRepresentable as Swift typealiases (guarded by #if os(macOS)). The pod now compiles Swift (SWIFT_VERSION) and links SwiftUI, so these types are exported to any module that does `import React_RCTUIKit`. - Remove the two non-functional SwiftUI @compatibility_alias entries from RCTUIKitCompat.h (nothing in Objective-C referenced them) and leave a note explaining why SwiftUI types must be declared in Swift. - Implement RCTPlatformViewWrapper with the concrete UI/NSViewRepresentable requirements (makeUIView/makeNSView + updateUIView/updateNSView); the previous makeRCTPlatformView/updateRCTPlatformView names did not satisfy either protocol. iOS behavior is unchanged (RCTPlatformHostingController -> UIHostingController, RCTPlatformViewRepresentable -> UIViewRepresentable). Validated locally with Xcode 26.4.1: a clean build of the RCTSwiftUI-macOS target and a full `RNTester-macOS` app build (arm64 + x86_64) both succeed. Note: the regressing PR microsoft#3006 merged just before microsoft#3007 ("ci(0.83): run PR checks on merge branch too"), so the merge-branch Build RNTester / macos job was not yet running when microsoft#3006 landed, which is why this compile break was not caught at merge time. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Saadnajmi
added a commit
to Saadnajmi/react-native-macos
that referenced
this pull request
Jul 7, 2026
PR microsoft#3006 moved the RCTSwiftUI platform types into the React_RCTUIKit Objective-C module via @compatibility_alias. That works for the Obj-C classes (RCTPlatformView -> UI/NSView, RCTPlatformColor -> UI/NSColor), which import into Swift fine, but it silently breaks for the SwiftUI types, so RCTSwiftUI-macOS fails to compile: RCTSwiftUIContainerView.swift: error: cannot find type 'RCTPlatformHostingController' in scope error: cannot find type 'RCTPlatformViewRepresentable' in scope error: cannot find type 'Context' in scope (x2) UI/NSHostingController and UI/NSViewRepresentable are Swift-only SwiftUI types (a generic class and a protocol). An Objective-C @compatibility_alias to them is not imported by Swift's Clang importer (and SwiftUI is not even imported in RCTUIKitCompat.h), so those two aliases resolve to nothing in Swift. The Context errors are secondary: once RCTPlatformViewRepresentable conformance is unknown, its associated Context type can't be resolved either. Fix (keeps microsoft#3006's intent of centralizing the platform types in React_RCTUIKit): - Add RCTUIKitCompat.swift to the React-RCTUIKit pod, which now compiles Swift (SWIFT_VERSION) and links SwiftUI so the types are exported to any module that does `import React_RCTUIKit`. It declares: - RCTPlatformHostingController: a Swift typealias to UI/NSHostingController. - RCTPlatformViewRepresentable: a protocol refining UI/NSViewRepresentable that bridges the platform requirements (makeUIView/makeNSView, etc.) to a unified makeRCTPlatformView/updateRCTPlatformView. A plain typealias can't work here because the two base protocols use different method names, so a conformer named makeRCTPlatformView would satisfy neither. - Remove the two non-functional SwiftUI @compatibility_alias entries from RCTUIKitCompat.h (nothing in Objective-C referenced them). - RCTPlatformViewWrapper now conforms to RCTPlatformViewRepresentable with the unified makeRCTPlatformView/updateRCTPlatformView, so the consumer no longer needs a per-platform #if. iOS behavior is unchanged. Validated locally with Xcode 26.4.1: a clean build of the RCTSwiftUI-macOS target and a full `RNTester-macOS` app build (arm64 + x86_64) both succeed. Note: the regressing PR microsoft#3006 merged just before microsoft#3007 ("ci(0.83): run PR checks on merge branch too"), so the merge-branch Build RNTester / macos job was not yet running when microsoft#3006 landed, which is why this compile break was not caught at merge time. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Saadnajmi
added a commit
to Saadnajmi/react-native-macos
that referenced
this pull request
Jul 7, 2026
PR microsoft#3006 moved the RCTSwiftUI platform types into the React_RCTUIKit Objective-C module via @compatibility_alias. That works for the Obj-C classes (RCTPlatformView -> UI/NSView, RCTPlatformColor -> UI/NSColor), which import into Swift fine, but it silently breaks for the SwiftUI types, so RCTSwiftUI-macOS fails to compile: RCTSwiftUIContainerView.swift: error: cannot find type 'RCTPlatformHostingController' in scope error: cannot find type 'RCTPlatformViewRepresentable' in scope error: cannot find type 'Context' in scope (x2) UI/NSHostingController and UI/NSViewRepresentable are Swift-only SwiftUI types (a generic class and a protocol). An Objective-C @compatibility_alias to them is not imported by Swift's Clang importer (and SwiftUI is not even imported in RCTUIKitCompat.h), so those two aliases resolve to nothing in Swift. The Context errors are secondary: once RCTPlatformViewRepresentable conformance is unknown, its associated Context type can't be resolved either. Fix (keeps microsoft#3006's intent of centralizing the platform types in React_RCTUIKit): - Add RCTUIKitCompat.swift to the React-RCTUIKit pod, which now compiles Swift (SWIFT_VERSION) and links SwiftUI so the types are exported to any module that does `import React_RCTUIKit`. It declares: - RCTPlatformHostingController: a Swift typealias to UI/NSHostingController. - RCTPlatformViewRepresentable: a protocol refining UI/NSViewRepresentable that bridges the platform requirements (makeUIView/makeNSView, etc.) to a unified makeRCTPlatformView/updateRCTPlatformView. A plain typealias can't work here because the two base protocols use different method names, so a conformer named makeRCTPlatformView would satisfy neither. - Remove the two non-functional SwiftUI @compatibility_alias entries from RCTUIKitCompat.h (nothing in Objective-C referenced them). - RCTPlatformViewWrapper now conforms to RCTPlatformViewRepresentable with the unified makeRCTPlatformView/updateRCTPlatformView, so the consumer no longer needs a per-platform #if. iOS behavior is unchanged. Validated locally with Xcode 26.4.1: a clean build of the RCTSwiftUI-macOS target and a full `RNTester-macOS` app build (arm64 + x86_64) both succeed. Note: the regressing PR microsoft#3006 merged just before microsoft#3007 ("ci(0.83): run PR checks on merge branch too"), so the merge-branch Build RNTester / macos job was not yet running when microsoft#3006 landed, which is why this compile break was not caught at merge time. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Saadnajmi
added a commit
to Saadnajmi/react-native-macos
that referenced
this pull request
Jul 7, 2026
PR microsoft#3006 moved the RCTSwiftUI platform types into the React_RCTUIKit Objective-C module via @compatibility_alias. That works for the Obj-C classes (RCTPlatformView -> UI/NSView, RCTPlatformColor -> UI/NSColor), which import into Swift fine, but it silently breaks for the SwiftUI types, so RCTSwiftUI-macOS fails to compile: RCTSwiftUIContainerView.swift: error: cannot find type 'RCTPlatformHostingController' in scope error: cannot find type 'RCTPlatformViewRepresentable' in scope error: cannot find type 'Context' in scope (x2) UI/NSHostingController and UI/NSViewRepresentable are Swift-only SwiftUI types (a generic class and a protocol). An Objective-C @compatibility_alias to them is not imported by Swift's Clang importer (and SwiftUI is not even imported in RCTUIKitCompat.h), so those two aliases resolve to nothing in Swift. The Context errors are secondary: once RCTPlatformViewRepresentable conformance is unknown, its associated Context type can't be resolved either. Fix: - Remove the two non-functional SwiftUI @compatibility_alias entries from RCTUIKitCompat.h (nothing in Objective-C referenced them). - Define RCTPlatformHostingController (a typealias to UI/NSHostingController) and RCTPlatformViewRepresentable (a protocol refining UI/NSViewRepresentable that bridges the platform requirements to a unified makeRCTPlatformView/ updateRCTPlatformView) in the RCTSwiftUI module that consumes them. They would ideally sit with the other RCTPlatform* aliases in React-RCTUIKit, but that module is Objective-C and SwiftPM does not support mixing Objective-C and Swift in one target, so they live in the consuming module for now. iOS behavior is unchanged, and React-RCTUIKit stays Objective-C only so the SwiftPM prebuild is unaffected. Validated locally with Xcode 26.4.1: a clean build of the RCTSwiftUI-macOS target and a full `RNTester-macOS` app build both succeed. Note: the regressing PR microsoft#3006 merged just before microsoft#3007 ("ci(0.83): run PR checks on merge branch too"), so the merge-branch Build RNTester / macos job was not yet running when microsoft#3006 landed, which is why this compile break was not caught at merge time. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Saadnajmi
added a commit
to Saadnajmi/react-native-macos
that referenced
this pull request
Jul 7, 2026
PR microsoft#3006 moved the RCTSwiftUI platform types into the React_RCTUIKit Objective-C module via @compatibility_alias. That works for the Obj-C classes (RCTPlatformView -> UI/NSView, RCTPlatformColor -> UI/NSColor), which import into Swift fine, but it silently breaks for the SwiftUI types, so RCTSwiftUI-macOS fails to compile: RCTSwiftUIContainerView.swift: error: cannot find type 'RCTPlatformHostingController' in scope error: cannot find type 'RCTPlatformViewRepresentable' in scope error: cannot find type 'Context' in scope (x2) UI/NSHostingController and UI/NSViewRepresentable are Swift-only SwiftUI types (a generic class and a protocol). An Objective-C @compatibility_alias to them is not imported by Swift's Clang importer (and SwiftUI is not even imported in RCTUIKitCompat.h), so those two aliases resolve to nothing in Swift. The Context errors are secondary: once RCTPlatformViewRepresentable conformance is unknown, its associated Context type can't be resolved either. Fix: - Remove the two non-functional SwiftUI @compatibility_alias entries from RCTUIKitCompat.h (nothing in Objective-C referenced them). - Define RCTPlatformHostingController (a typealias to UI/NSHostingController) and RCTPlatformViewRepresentable (a protocol refining UI/NSViewRepresentable that bridges the platform requirements to a unified makeRCTPlatformView/ updateRCTPlatformView) in the RCTSwiftUI module that consumes them. They would ideally sit with the other RCTPlatform* aliases in React-RCTUIKit, but that module is Objective-C and SwiftPM does not support mixing Objective-C and Swift in one target, so they live in the consuming module for now. iOS behavior is unchanged, and React-RCTUIKit stays Objective-C only so the SwiftPM prebuild is unaffected. Validated locally with Xcode 26.4.1: a clean build of the RCTSwiftUI-macOS target and a full `RNTester-macOS` app build both succeed. Note: the regressing PR microsoft#3006 merged just before microsoft#3007 ("ci(0.83): run PR checks on merge branch too"), so the merge-branch Build RNTester / macos job was not yet running when microsoft#3006 landed, which is why this compile break was not caught at merge time. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Saadnajmi
added a commit
to Saadnajmi/react-native-macos
that referenced
this pull request
Jul 7, 2026
PR microsoft#3006 moved the RCTSwiftUI platform types into the React_RCTUIKit Objective-C module via @compatibility_alias. That works for the Obj-C classes (RCTPlatformView -> UI/NSView, RCTPlatformColor -> UI/NSColor), which import into Swift fine, but it silently breaks for the SwiftUI types, so RCTSwiftUI-macOS fails to compile: RCTSwiftUIContainerView.swift: error: cannot find type 'RCTPlatformHostingController' in scope error: cannot find type 'RCTPlatformViewRepresentable' in scope error: cannot find type 'Context' in scope (x2) UI/NSHostingController and UI/NSViewRepresentable are Swift-only SwiftUI types (a generic class and a protocol). An Objective-C @compatibility_alias to them is not imported by Swift's Clang importer (and SwiftUI is not even imported in RCTUIKitCompat.h), so those two aliases resolve to nothing in Swift. The Context errors are secondary: once RCTPlatformViewRepresentable conformance is unknown, its associated Context type can't be resolved either. Fix: - Remove the two non-functional SwiftUI @compatibility_alias entries from RCTUIKitCompat.h (nothing in Objective-C referenced them). - Define RCTPlatformHostingController (a typealias to UI/NSHostingController) and RCTPlatformViewRepresentable (a protocol refining UI/NSViewRepresentable that bridges the platform requirements to a unified makeRCTPlatformView/ updateRCTPlatformView) in the RCTSwiftUI module that consumes them. They would ideally sit with the other RCTPlatform* aliases in React-RCTUIKit, but that module is Objective-C and SwiftPM does not support mixing Objective-C and Swift in one target, so they live in the consuming module for now. - Package.swift: make the RCTSwiftUI / RCTSwiftUIWrapper SwiftPM targets depend on React-RCTUIKit. microsoft#3006 added that pod dependency but did not update Package.swift, so `import React_RCTUIKit` failed with "no such module" in the SwiftPM prebuild. iOS behavior is unchanged, and React-RCTUIKit stays Objective-C only so its SwiftPM target is not turned into an unsupported mixed-language target. Validated locally with Xcode 26.4.1: clean builds of the RCTSwiftUI-macOS Pods target and the full RNTester-macOS app, plus the SwiftPM prebuild (`node scripts/ios-prebuild.js -s`/`-b -p macos`) now compiles React_RCTUIKit, RCTSwiftUI and RCTSwiftUIWrapper without the "no such module" error. Note: the regressing PR microsoft#3006 merged just before microsoft#3007 ("ci(0.83): run PR checks on merge branch too"), so the merge-branch Build RNTester / macos job was not yet running when microsoft#3006 landed, which is why this compile break was not caught at merge time. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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 free
to 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:
To aid in the merge
Test Plan:
CI should pass