Fix playground composition for Node.js 24.x#15983
Merged
vmoroz merged 8 commits intomicrosoft:mainfrom Apr 21, 2026
Merged
Conversation
NikoAri
approved these changes
Apr 10, 2026
Performance Test ResultsBranch: ✅ Passed161 scenario(s) across 28 suite(s) — no regressionsSectionList
FlatList
TouchableOpacity
ScrollView
TouchableHighlight
Pressable
Modal
Image
ActivityIndicator
Switch
Button
TextInput
View
Text
SectionList.native-perf-test.ts
FlatList.native-perf-test.ts
TouchableHighlight.native-perf-test.ts
TouchableOpacity.native-perf-test.ts
Pressable.native-perf-test.ts
ScrollView.native-perf-test.ts
ActivityIndicator.native-perf-test.ts
TextInput.native-perf-test.ts
Switch.native-perf-test.ts
Button.native-perf-test.ts
Modal.native-perf-test.ts
Image.native-perf-test.ts
View.native-perf-test.ts
Text.native-perf-test.ts
|
25b00f9 to
d711a3b
Compare
acoates-ms
approved these changes
Apr 20, 2026
7031750 to
1fbf70c
Compare
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
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.
Description
Type of Change
Why
Fix regressions introduced by PR #15979 ("Use fork-sync for Folly and FastFloat") and compatibility issues with Node v24 / npm v11 that broke the
playground-compositionsolution: build failures, Metro bundler crashes, and runtime errors preventing the RNTester UI from loading.What
1. Remove stale Folly project references after fork-sync migration
PR #15979 moved Folly into
vnext/external/folly/folly.vcxitems(a shared items project), but left behind direct references to the old standaloneFolly.vcxprojin several places. These caused duplicate item errors and missing project errors:Microsoft.ReactNative.vcxproj: removed<Natvis>and<ProjectReference>entries pointing at the oldFolly.vcxprojMicrosoft.ReactNative.vcxproj.filters: updated Natvis path from$(ReactNativeWindowsDir)Folly\to$(ExternalDir)folly\Playground-Composition.vcxproj: removed stale<Natvis>reference to$(ReactNativeWindowsDir)Folly\Folly.natvisplayground-composition.sln: removed theFollyproject entry and its build configurations; removed theReactCommon->FollydependencyReact.Cpp.props: updatedAdditionalIncludeDirectoriesfrom$(FollyDir)/$(FastFloatDir)includeto$(ExternalDir)folly/$(ExternalDir)fast-float\includepackages.lock.json,packages.experimentalwinui3.lock.json) inMicrosoft.ReactNative,playground-composition, andplayground-composition.Package: removed staleFollyproject dependency entries2. Fix build order in
playground-composition.slnSampleCustomComponentprocessesDrawingIsland.idlwhich importsMicrosoft.ReactNative.winmd. BecauseSampleCustomComponenthad no declared dependency onMicrosoft.ReactNative, Visual Studio could start building it beforeMicrosoft.ReactNativewas ready, causing:Fix: added
ProjectDependenciessection to theSampleCustomComponentproject entry in the solution file, declaring a dependency onMicrosoft.ReactNative.3. Fix
yarn start/yarn windowsfor the playground packageThe
startandwindowsscripts usednpx @react-native-community/cli <cmd>, which invokes npm 11's arborist to scan the workspace tree. npm 11 crashes withCannot read properties of null (reading 'package')when it encounters the Yarn-managednode_modulesstructure.Fix: replaced
npx @react-native-community/cliwith thereact-nativebinary directly, which is provided by@react-native-community/cli(already a devDependency) and is available onPATHwhen run via yarn without going through npm's arborist.4. Fix MSBuild CLI invocations crashing with npm v11 in yarn workspaces
Three MSBuild property sheets run
npx @react-native-community/cli <command>during build. In npm v11.8.0 (bundled with Node v24),npxcallsExec.execWorkspaceswhich tries to build an npm arborist tree. Since this repo uses Yarn workspaces, the arborist fails:Fix: added
--no-workspacesflag to all three property sheets to skip npm's workspace tree resolution, which is not needed for running the CLI:Codegen.props: codegen-windows commandAutolink.props: autolink-windows commandBundle.props: bundle command5. Fix Metro resolver failing to find
react-nativemodules (Node v24 + Windows)On Windows,
require.resolve()through yarn workspace junctions (e.g.node_modules/react-native-windows->vnext/) returns paths with a different drive letter case thanprocess.cwd()in Node v24. Metro's internal file system tree derives its paths fromprocess.cwd(), andfileSystemLookupuses case-sensitive string comparison, so all resolved module paths from the playground's customdevResolveRequestresolver failed to match:Fix: added
normalizePathDrive()helper in the playground'smetro.config.jsand the three app/lib template metro configs (vnext/template/metro.config.js,vnext/templates/cpp-app/metro.config.js,vnext/templates/cpp-lib/example/metro.config.js) to normalize the drive letter to matchprocess.cwd()afterfs.realpathSync/require.resolve.6. Fix
InitializeCore.jsnot running before main module (Node v24 + Windows)The
getModulesRunBeforeMainModulepaths (computed by@rnx-kit/metro-configviarequire.resolve) also had the wrong drive letter case. Metro'sgetAppendScriptscompares these paths against module paths in the bundle graph using strict equality (===). The case mismatch causedInitializeCore.jsto silently not be required before the main module, sosetUpGlobals.jsnever ranglobal.window = global, leading to:Fix: overrode
getModulesRunBeforeMainModulein the playground'smetro.config.jsto normalize paths throughfs.realpathSync+normalizePathDrive(), ensuring they match the resolved module paths in the bundle graph.7. Fix Universal solution (
Microsoft.ReactNative.NewArch.sln) compilation in Visual StudioVS's NuGet restore fails with NU1004 for
Microsoft.ReactNative.CsWinRT.csprojbecause VS uses the CPS nomination API to evaluate project references, while the lock files are generated bymsbuild /t:Restorewhich fully evaluates vcxproj targets. When a .csproj references a .vcxproj, VS's NuGet restore only discovers ProjectReferences (Common.vcxproj, ReactCommon.vcxproj), but the lock file also contains the vcxproj's PackageReferences (boost, Hermes, SourceLink, etc.) — causing a mismatch.Two fixes:
NuGet.LockFile.props: disableRestoreLockedModefor .csproj files whenBuildingInsideVisualStudio=true, so VS's initial NuGet restore succeeds and package targets load correctly. CI is unaffected because it passes/p:RestoreLockedMode=trueas a global property which overrides project-level settings.Directory.Build.targets: extend the existingBeforeResolveReferencesworkaround (which already handles vcxproj PackageReference restore in VS) to also cover .csproj files, providing an explicitmsbuild /t:Restorefallback during the build.Screenshots
N/A
Testing
packages/playground/windows/playground-composition.sln(Debug|x64) successfully.yarn startfrompackages/playgroundlaunches the Metro bundler without errors.vnext/Microsoft.ReactNative.NewArch.sln(Debug|x64) in Visual Studio successfully.Changelog
Should this change be included in the release notes: no