Use fork-sync and make a local copy of fmt

[vmoroz]

Description

Type of Change

• New feature (non-breaking change which adds functionality)

Why

Third-party dependencies in RNW (fmt, Folly, ReactCommon) use a bespoke
MSBuild download-unzip-overlay pipeline that has no conflict detection, no
3-way merge, and duplicates the same concepts per library. This PR begins
adopting @rnx-kit/fork-sync — the same tool used in hermes-windows — to get
Git 3-way merges, AI-assisted conflict resolution, and a unified
manifest-driven workflow.

fmt is the first dependency to migrate because it is the simplest case: a
small library with no active patches.

What

Phase 0 — fork-sync infrastructure:

• Created @rnw-scripts/fork-sync package — thin wrapper that invokes
  @rnx-kit/fork-sync with -C pointing to the repo root.
• Added sync-manifest.json at the repo root listing fmt as the first
  managed dependency.
• Added /.sync/ to .gitignore (fork-sync's working directory).
• Added fork-sync and fork-sync:status scripts to root package.json.

Phase 1 — migrate fmt to fork-sync:

• Committed fmt 11.0.2 source into vnext/external/fmt/ with
  sync-config.json, .syncignore, and cgmanifest.json.
• Added vnext/external/.clang-format (DisableFormat: true) to prevent
  formatting of vendored source files.
• Added vnext/external to .unbroken_exclusions to skip link checking
  in vendored docs.
• Each external dependency gets its own .vcxitems file next to its
  source (e.g., vnext/external/fmt/fmt.vcxitems). A top-level
  vnext/external/External.vcxitems aggregates all per-dependency items
  and applies shared compiler settings via a single
  <ClCompile Update="$(ExternalDir)**"> block. Shared.vcxitems
  imports External.vcxitems with one line — keeping vendored code
  cleanly separated from RNW's own source.
• Defined $(ExternalDir) in Directory.Build.props pointing to
  vnext\external\.
• Updated fmt include paths in React.Cpp.props, Folly.vcxproj, and
  Microsoft.ReactNative.vcxproj from $(FmtDir)include to
  $(ExternalDir)fmt\include.
• Removed FmtVersion, FmtCommitHash, and FmtDir properties from
  Directory.Build.props.
• Updated Layout-Desktop-Headers.ps1 to use committed fmt source
  instead of downloading.
• Deleted vnext/fmt/ directory (vcxproj, filters, pch files,
  clang-format, packages.lock.json).
• Removed fmt project entry and build configurations from 12 .sln files
  and 2 .slnf files.
• Removed ProjectReference to fmt from Folly.vcxproj.

Screenshots

N/A

Testing

• Built Microsoft.ReactNative.vcxproj (Debug|x64) — fmt compiles
  correctly via the vcxitems chain.
• Built Folly.vcxproj (Debug|x64) — finds fmt headers via updated
  include path.
• Built React.Windows.Desktop.DLL.vcxproj (Debug|x64) — Desktop target
  also works.
• Verified yarn format no longer reformats vendored fmt source (thanks
  to vnext/external/.clang-format).

Changelog

Should this change be included in the release notes: no

[Saadnajmi]

Can we not pull fmt as a package and patch it if need be? Do we need a source copy?

[vmoroz]

Can we not pull fmt as a package and patch it if need be? Do we need a source copy?

All major OSS projects typically have a local copy of 3rd party code. It makes it easy to support them.
For us having the sources in our repo makes it easy to investigate issues in the crash dumps and do any quick changes.
The new fork-sync tool makes it trivial to support such local forks.

[Saadnajmi]

Can we not pull fmt as a package and patch it if need be? Do we need a source copy?

All major OSS projects typically have a local copy of 3rd party code. It makes it easy to support them.
For us having the sources in our repo makes it easy to investigate issues in the crash dumps and do any quick changes.
The new fork-sync tool makes it trivial to support such local forks.

That's not true? Most OSS projects use a package or dep manager to download them?

[vmoroz]

That's not true? Most OSS projects use a package or dep manager to download them?

I am referring to Node.js and V8 OSS projects. A number of other projects do the same, e.g. Hermes.
These changes were already discussed with other RNW team members.
Let's continue this discussion offline.

[Saadnajmi]

That's not true? Most OSS projects use a package or dep manager to download them?

I am referring to Node.js and V8 OSS projects. A number of other projects do the same, e.g. Hermes. These changes were already discussed with other RNW team members. Let's continue this discussion offline.

I'll trust your judgement. It's not my prefernce but I am sure you have weighed the tradeoffs for RNW.

[JunielKatarn]

Moved fmt ClCompile/ClInclude entries into Shared.vcxitems — fmt is
now compiled inline instead of as a separate static library.

I would argue against this.
Shared should be scoped only to RNW sources ultimately built into the Desktop and modern DLLs, not third-party code.

Got two questions:

1. Why not keep the static library?
2. If the static library is a problem, why not create a separate VCXITEMS project (similar to shared) dedicated to fmt (i.e. fmt.vcxitems)?

[github-actions]

Performance Test Results

Branch: PR/fork-sync-fmt
Commit: 76f569b9
Time: 2026-04-07T00:49:35.411Z
Tests: 160/161 passed

❌ Regressions Detected

TouchableHighlight

Scenario	Baseline	Current	Change	Status
TouchableHighlight multiple-touchables-50	13.00ms	19.00ms	+60.0%	❌

TouchableHighlight multiple-touchables-50: Duration increased by 60.0% / +7.50ms (threshold: 15% & 5ms)

✅ Passed

149 scenario(s) across 27 suite(s) — no regressions

SectionList

Scenario	Mean	Median	StdDev	Renders	vs Baseline
SectionList mount	5.80ms	5.00ms	±1.55ms	1	+0.0%
SectionList unmount	0.20ms	0.00ms	±0.42ms	0	+0.0%
SectionList rerender	13.50ms	13.00ms	±3.27ms	2	+23.8%
SectionList with-3-sections-15-items	7.00ms	6.00ms	±2.16ms	1	+9.1%
SectionList with-5-sections-50-items	7.40ms	6.50ms	±2.12ms	1	+8.3%
SectionList with-10-sections-200-items	7.20ms	6.50ms	±1.69ms	1	+18.2%
SectionList with-20-sections-200-items	5.20ms	5.00ms	±1.87ms	1	+0.0%
SectionList with-section-separator	2.60ms	2.00ms	±2.27ms	1	+0.0%
SectionList with-item-separator	3.40ms	3.00ms	±1.51ms	1	+50.0%
SectionList with-header-footer	2.60ms	2.00ms	±1.07ms	1	+0.0%
SectionList with-section-footer	3.10ms	2.50ms	±2.13ms	1	+25.0%
SectionList with-sticky-section-headers	2.10ms	2.00ms	±1.10ms	1	+0.0%
SectionList with-empty-list	0.50ms	0.50ms	±0.53ms	1	-50.0%
SectionList with-50-sections-1000-items	3.20ms	2.50ms	±1.87ms	1	+25.0%

FlatList

Scenario	Mean	Median	StdDev	Renders	vs Baseline
FlatList mount	5.00ms	5.00ms	±0.82ms	1	+25.0%
FlatList unmount	0.20ms	0.00ms	±0.42ms	0	+0.0%
FlatList rerender	12.60ms	11.00ms	±3.84ms	2	+22.2%
FlatList with-10-items	5.80ms	5.00ms	±2.15ms	1	+25.0%
FlatList with-100-items	5.60ms	5.50ms	±1.43ms	1	+10.0%
FlatList with-500-items	5.70ms	5.00ms	±1.83ms	1	+25.0%
FlatList with-1000-items	4.70ms	4.50ms	±1.16ms	1	+12.5%
FlatList horizontal	6.40ms	6.00ms	±1.78ms	1	+20.0%
FlatList with-separator	2.00ms	2.00ms	±0.47ms	1	+0.0%
FlatList with-header-footer	1.80ms	2.00ms	±0.42ms	1	+0.0%
FlatList with-empty-list	0.20ms	0.00ms	±0.42ms	1	-100.0%
FlatList with-get-item-layout	2.00ms	2.00ms	±0.82ms	1	+100.0%
FlatList inverted	1.60ms	2.00ms	±0.52ms	1	+33.3%
FlatList with-num-columns	3.50ms	3.00ms	±2.17ms	1	+0.0%

TouchableOpacity

Scenario	Mean	Median	StdDev	Renders	vs Baseline
TouchableOpacity mount	0.50ms	0.50ms	±0.53ms	1	-50.0%
TouchableOpacity unmount	0.00ms	0.00ms	±0.00ms	0	+0.0%
TouchableOpacity rerender	1.40ms	1.00ms	±0.52ms	2	+0.0%
TouchableOpacity custom-active-opacity	0.60ms	1.00ms	±0.52ms	1	+0.0%
TouchableOpacity disabled	0.60ms	1.00ms	±0.52ms	1	+0.0%
TouchableOpacity with-all-handlers	1.10ms	1.00ms	±0.32ms	1	+0.0%
TouchableOpacity with-hit-slop	1.10ms	1.00ms	±0.32ms	1	+0.0%
TouchableOpacity with-delay	1.00ms	1.00ms	±0.47ms	1	+0.0%
TouchableOpacity nested	1.80ms	2.00ms	±0.42ms	1	+100.0%
TouchableOpacity multiple-10	7.53ms	7.00ms	±2.17ms	1	+16.7%
TouchableOpacity multiple-50	33.40ms	32.00ms	±6.08ms	1	+10.3%
TouchableOpacity multiple-100	51.07ms	49.00ms	±12.23ms	1	-2.0%

ScrollView

Scenario	Mean	Median	StdDev	Renders	vs Baseline
ScrollView mount	1.10ms	1.00ms	±1.45ms	1	+Infinity%
ScrollView unmount	0.00ms	0.00ms	±0.00ms	0	+0.0%
ScrollView rerender	0.60ms	1.00ms	±0.52ms	2	+0.0%
ScrollView children-20	3.40ms	3.00ms	±0.91ms	1	-25.0%
ScrollView children-100	19.73ms	19.00ms	±5.26ms	1	+18.8%
ScrollView horizontal	3.70ms	3.00ms	±1.06ms	1	-25.0%
ScrollView sticky-headers	3.00ms	3.00ms	±1.70ms	1	+0.0%
ScrollView scroll-indicators	0.80ms	1.00ms	±0.42ms	1	+0.0%
ScrollView nested	1.50ms	1.00ms	±0.97ms	1	+0.0%
ScrollView content-container-style	0.80ms	1.00ms	±0.42ms	1	+0.0%
ScrollView children-500	23.47ms	21.00ms	±6.53ms	1	+10.5%

Pressable

Scenario	Mean	Median	StdDev	Renders	vs Baseline
Pressable mount	0.50ms	0.50ms	±0.53ms	1	+Infinity%
Pressable unmount	0.00ms	0.00ms	±0.00ms	0	+0.0%
Pressable rerender	0.60ms	1.00ms	±0.52ms	2	+100.0%
Pressable with-all-handlers	0.50ms	0.50ms	±0.53ms	1	+Infinity%
Pressable with-style-function	0.40ms	0.00ms	±0.52ms	1	+0.0%
Pressable disabled	1.00ms	0.50ms	±1.83ms	1	+Infinity%
Pressable with-hit-slop	0.30ms	0.00ms	±0.48ms	1	+0.0%
Pressable nested	0.70ms	1.00ms	±0.48ms	1	+0.0%
Pressable multiple-10	3.13ms	3.00ms	±0.64ms	1	+0.0%
Pressable multiple-50	19.60ms	19.00ms	±3.18ms	1	+35.7%
Pressable multiple-100	20.20ms	15.00ms	±12.30ms	1	+25.0%

Modal

Scenario	Mean	Median	StdDev	Renders	vs Baseline
Modal mount	0.20ms	0.00ms	±0.42ms	1	+0.0%
Modal unmount	0.00ms	0.00ms	±0.00ms	0	+0.0%
Modal rerender	0.30ms	0.00ms	±0.48ms	2	+0.0%
Modal slide-animation	0.50ms	0.50ms	±0.53ms	1	+Infinity%
Modal fade-animation	0.50ms	0.50ms	±0.53ms	1	+Infinity%
Modal transparent	0.40ms	0.00ms	±0.52ms	1	+0.0%
Modal with-callbacks	0.50ms	0.00ms	±1.27ms	1	+0.0%
Modal rich-content	1.50ms	1.50ms	±0.53ms	1	-25.0%
Modal with-accessibility	0.40ms	0.00ms	±0.52ms	1	+0.0%

Image

Scenario	Mean	Median	StdDev	Renders	vs Baseline
Image mount	0.00ms	0.00ms	±0.00ms	1	+0.0%
Image unmount	0.10ms	0.00ms	±0.32ms	0	+0.0%
Image rerender	0.80ms	0.50ms	±1.23ms	2	+Infinity%
Image with-resize-mode	0.30ms	0.00ms	±0.48ms	1	+0.0%
Image with-border-radius	0.20ms	0.00ms	±0.42ms	1	+0.0%
Image with-tint-color	0.10ms	0.00ms	±0.32ms	1	+0.0%
Image with-blur-radius	0.10ms	0.00ms	±0.32ms	1	+0.0%
Image with-accessibility	0.20ms	0.00ms	±0.42ms	1	+0.0%
Image multiple-10	1.00ms	1.00ms	±0.00ms	1	+0.0%
Image multiple-50	4.13ms	4.00ms	±1.06ms	1	+33.3%
Image multiple-100	9.40ms	8.00ms	±2.10ms	1	+0.0%

ActivityIndicator

Scenario	Mean	Median	StdDev	Renders	vs Baseline
ActivityIndicator mount	0.10ms	0.00ms	±0.32ms	1	+0.0%
ActivityIndicator unmount	0.00ms	0.00ms	±0.00ms	0	+0.0%
ActivityIndicator rerender	0.30ms	0.00ms	±0.48ms	2	+0.0%
ActivityIndicator size-large	0.20ms	0.00ms	±0.42ms	1	+0.0%
ActivityIndicator size-small	0.20ms	0.00ms	±0.42ms	1	+0.0%
ActivityIndicator with-color	0.10ms	0.00ms	±0.32ms	1	+0.0%
ActivityIndicator not-animating	0.10ms	0.00ms	±0.32ms	1	+0.0%
ActivityIndicator with-accessibility	0.30ms	0.00ms	±0.48ms	1	+0.0%
ActivityIndicator multiple-10	1.00ms	1.00ms	±0.00ms	1	+0.0%
ActivityIndicator multiple-50	4.27ms	4.00ms	±1.67ms	1	+0.0%
ActivityIndicator multiple-100	9.73ms	10.00ms	±2.31ms	1	+42.9%

Switch

Scenario	Mean	Median	StdDev	Renders	vs Baseline
Switch mount	0.30ms	0.00ms	±0.48ms	1	+0.0%
Switch unmount	0.10ms	0.00ms	±0.32ms	0	+0.0%
Switch rerender	0.40ms	0.00ms	±0.52ms	2	-100.0%
Switch value-true	0.10ms	0.00ms	±0.32ms	1	+0.0%
Switch disabled	0.30ms	0.00ms	±0.48ms	1	+0.0%
Switch custom-colors	0.40ms	0.00ms	±0.52ms	1	+0.0%
Switch on-value-change	0.20ms	0.00ms	±0.42ms	1	+0.0%
Switch with-accessibility	0.30ms	0.00ms	±0.48ms	1	+0.0%
Switch multiple-10	1.73ms	2.00ms	±0.46ms	1	+0.0%
Switch multiple-50	11.87ms	10.00ms	±4.53ms	1	+11.1%
Switch multiple-100	22.93ms	22.00ms	±5.47ms	1	+37.5%

Button

Scenario	Mean	Median	StdDev	Renders	vs Baseline
Button mount	1.00ms	1.00ms	±0.00ms	1	+0.0%
Button unmount	0.10ms	0.00ms	±0.32ms	0	+0.0%
Button rerender	1.20ms	1.00ms	±0.42ms	2	+0.0%
Button disabled	0.80ms	1.00ms	±0.42ms	1	+0.0%
Button with-color	0.60ms	1.00ms	±0.52ms	1	+100.0%
Button with-accessibility	0.60ms	1.00ms	±0.52ms	1	+0.0%
Button multiple-10	6.87ms	6.00ms	±2.07ms	1	+0.0%
Button multiple-50	25.20ms	27.00ms	±9.73ms	1	+0.0%
Button multiple-100	18.07ms	15.00ms	±5.06ms	1	-21.1%

TextInput

Scenario	Mean	Median	StdDev	Renders	vs Baseline
TextInput mount	0.20ms	0.00ms	±0.42ms	1	+0.0%
TextInput unmount	0.00ms	0.00ms	±0.00ms	0	+0.0%
TextInput rerender	0.30ms	0.00ms	±0.48ms	2	+0.0%
TextInput multiline	0.20ms	0.00ms	±0.42ms	1	+0.0%
TextInput with-value	0.20ms	0.00ms	±0.42ms	1	+0.0%
TextInput styled	0.20ms	0.00ms	±0.42ms	1	+0.0%
TextInput multiple-100	9.73ms	9.00ms	±2.96ms	1	+28.6%

View

Scenario	Mean	Median	StdDev	Renders	vs Baseline
View mount	0.20ms	0.00ms	±0.42ms	1	+0.0%
View unmount	0.00ms	0.00ms	±0.00ms	0	+0.0%
View rerender	0.10ms	0.00ms	±0.32ms	2	+0.0%
View nested-50	3.80ms	4.00ms	±0.56ms	1	+33.3%
View nested-100	9.40ms	8.00ms	±2.50ms	1	+14.3%
View shadow	0.20ms	0.00ms	±0.42ms	1	+0.0%
View border-radius	0.20ms	0.00ms	±0.42ms	1	+0.0%
View nested-500	18.40ms	10.00ms	±14.27ms	1	+0.0%

Text

Scenario	Mean	Median	StdDev	Renders	vs Baseline
Text mount	0.20ms	0.00ms	±0.42ms	1	+0.0%
Text unmount	0.20ms	0.00ms	±0.42ms	0	+0.0%
Text rerender	0.20ms	0.00ms	±0.42ms	2	+0.0%
Text long-1000	0.20ms	0.00ms	±0.42ms	1	+0.0%
Text nested	0.30ms	0.00ms	±0.48ms	1	+0.0%
Text styled	0.20ms	0.00ms	±0.42ms	1	+0.0%
Text multiple-100	8.93ms	9.00ms	±1.33ms	1	+28.6%

SectionList.native-perf-test.ts

Scenario	Mean	Median	StdDev	Renders	vs Baseline
SectionList native mount	6.74ms	6.78ms	±0.93ms	1	+4.2%

FlatList.native-perf-test.ts

Scenario	Mean	Median	StdDev	Renders	vs Baseline
FlatList native mount	6.42ms	6.41ms	±0.82ms	1	-30.5%

TouchableHighlight.native-perf-test.ts

Scenario	Mean	Median	StdDev	Renders	vs Baseline
TouchableHighlight native mount	1.94ms	1.79ms	±0.70ms	1	-14.3%

TouchableOpacity.native-perf-test.ts

Scenario	Mean	Median	StdDev	Renders	vs Baseline
TouchableOpacity native mount	2.53ms	2.20ms	±0.83ms	1	-30.0%

Pressable.native-perf-test.ts

Scenario	Mean	Median	StdDev	Renders	vs Baseline
Pressable native mount	2.18ms	2.16ms	±0.39ms	1	-13.9%

ScrollView.native-perf-test.ts

Scenario	Mean	Median	StdDev	Renders	vs Baseline
ScrollView native mount	3.96ms	4.00ms	±0.41ms	1	-1.3%

ActivityIndicator.native-perf-test.ts

Scenario	Mean	Median	StdDev	Renders	vs Baseline
ActivityIndicator native mount	1.76ms	1.70ms	±0.25ms	1	-31.4%

TextInput.native-perf-test.ts

Scenario	Mean	Median	StdDev	Renders	vs Baseline
TextInput native mount	2.61ms	2.42ms	±0.46ms	1	-40.7%

Switch.native-perf-test.ts

Scenario	Mean	Median	StdDev	Renders	vs Baseline
Switch native mount	1.59ms	1.50ms	±0.22ms	1	-13.6%

Button.native-perf-test.ts

Scenario	Mean	Median	StdDev	Renders	vs Baseline
Button native mount	2.27ms	2.08ms	±0.34ms	1	-20.1%

Modal.native-perf-test.ts

Scenario	Mean	Median	StdDev	Renders	vs Baseline
Modal native mount	1.32ms	1.27ms	±0.16ms	1	+4.6%

Image.native-perf-test.ts

Scenario	Mean	Median	StdDev	Renders	vs Baseline
Image native mount	2.19ms	2.13ms	±0.44ms	1	-5.9%

View.native-perf-test.ts

Scenario	Mean	Median	StdDev	Renders	vs Baseline
View native mount	1.51ms	1.36ms	±0.49ms	1	-4.8%

Text.native-perf-test.ts

Scenario	Mean	Median	StdDev	Renders	vs Baseline
Text native mount	1.66ms	1.64ms	±0.14ms	1	-5.8%

[vmoroz]

Moved fmt ClCompile/ClInclude entries into Shared.vcxitems — fmt is
now compiled inline instead of as a separate static library.

I would argue against this. Shared should be scoped only to RNW sources ultimately built into the Desktop and modern DLLs, not third-party code.

Got two questions:

1. Why not keep the static library?
2. If the static library is a problem, why not create a separate VCXITEMS project (similar to shared) dedicated to fmt (i.e. fmt.vcxitems)?

The static libraries create unnecessary artifacts and may affect the speed and quality of compilations.
I like the idea about the vcxitems per external project and the latest commit implemented the chenge.