{"owner":"microsoft","repo":"react-native-windows","hasSkills":true,"totalSkillsCount":28,"totalTokensCount":25166,"categories":["copilot-instructions","anthropic-skill","plugin-manifest"],"hasMcp":false,"mcpConfig":null,"found":[".github/copilot-instructions.md",".github/skills/rnw-integration/README.md",".github/skills/rnw-integration/SKILL.md",".github/skills/rnw-integration/references/conflict-patterns.md","packages/@office-iss/react-native-win32/README.md","packages/@react-native-windows/automation-channel/README.md","packages/@react-native-windows/automation-commands/README.md","packages/@react-native-windows/automation/README.md","packages/@react-native-windows/cli/README.md","packages/@react-native-windows/codegen/README.md","packages/@react-native-windows/find-dotnet-tools/README.md","packages/@react-native-windows/fs/README.md","packages/@react-native-windows/perf-testing/README.md","packages/@react-native-windows/telemetry/README.md","packages/@react-native/tester/js/examples/Experimental/PlatformTest/README.md","packages/@rnw-scripts/doxysaurus/README.md","packages/@rnw-scripts/generate-release-notes/ReadMe.md","packages/@rnw-scripts/metro-dev-config/README.md","packages/@rnw-scripts/stamp-version/README.md","packages/@rnw-scripts/warm-feed/README.md","packages/README.md","packages/debug-test/README.md","packages/e2e-test-app-fabric/README.md","packages/playground/README.md","packages/react-native-platform-override/README.md","packages/react-native-platform-override/src/e2etest/collateral/sampleOverrideRepo/README.md","packages/react-native-windows-init/README.md","packages/sample-app-fabric/README.md"],"skills":{".github/copilot-instructions.md":"# GitHub Copilot Instructions for React Native Windows\n\nThis file provides guidance to GitHub Copilot for contributing to the React Native Windows repository. React Native Windows brings React Native to the Windows platform, supporting both UWP and Win32 applications.\n\n## Project Overview\n\nReact Native Windows is a Microsoft-maintained implementation of React Native that targets Windows platforms. The repository is a monorepo containing:\n\n- **Native Windows implementation** (C++/C#) for React Native runtime\n- **JavaScript/TypeScript tooling** for development experience\n- **Sample applications** and test suites\n- **Documentation** and build tools\n\n### Key Architecture Components\n\n- **Paper Architecture** (legacy): UWP XAML-based renderer\n- **Fabric Architecture** (new): Win32 Composition-based renderer with WinAppSDK\n- **Native Modules**: Platform-specific functionality exposed to JavaScript\n- **View Managers**: Custom UI components\n- **Turbo Modules**: New native module system with better performance\n\n## Repository Structure\n\n```\n├── .github/ # GitHub configuration and templates\n├── docs/ # Documentation\n├── packages/ # Monorepo packages\n│ ├── @react-native-windows/ # Core RNW packages\n│ └── @rnw-scripts/ # Build and development tools\n├── vnext/ # Main C++/C# implementation\n└── tools/ # Development utilities\n```\n\n## Coding Standards and Conventions\n\n### C++ Code (.cpp, .h files)\n\n- While raising a PR don't do any changes in vnext/codegen directory, that directory should be untouched.\n\n**Style Guide**: Follow the project's `.clang-format` configuration\n- **Line length**: 120 characters maximum\n- **Indentation**: 2 spaces, no tabs\n- **Pointer alignment**: Right-aligned (`int *ptr`, not `int* ptr`)\n- **Braces**: Attach style (same line as control statements)\n- **Naming**: \n - PascalCase for classes, methods, and properties\n - camelCase for local variables and parameters\n - UPPER_CASE for constants and macros\n\n```cpp\n// Good C++ style\nclass WindowsTextInput : public ViewManagerBase {\n public:\n WindowsTextInput(IReactContext const &reactContext);\n \n void SetText(std::wstring const &text) {\n m_text = text;\n }\n \n private:\n std::wstring m_text;\n};\n```\n\n**Key Patterns**:\n- Use `IReactContext` for accessing React Native context\n- Prefer `winrt::` types for Windows Runtime interop\n- Use `std::shared_ptr` for shared ownership\n- Follow RAII principles for resource management\n\n### C# Code (.cs files)\n\n**Style Guide**: Follow Microsoft C# conventions\n- **Indentation**: 4 spaces\n- **Line endings**: CRLF (Windows style)\n- **Naming**: PascalCase for public members, camelCase for private fields with underscore prefix\n\n```csharp\n// Good C# style\npublic sealed class ReactNativeModule\n{\n private readonly IReactContext _reactContext;\n \n public ReactNativeModule(IReactContext reactContext)\n {\n _reactContext = reactContext ?? throw new ArgumentNullException(\"reactContext\");\n }\n \n [ReactMethod]\n public void ShowAlert(string message)\n {\n // Implementation\n }\n}\n```\n\n**Key Patterns**:\n- Use `[ReactMethod]` attribute for methods exposed to JavaScript\n- Use `[ReactProperty]` for bindable properties in view managers\n- Prefer `sealed` classes for performance\n- Use nullable reference types where appropriate\n\n### TypeScript/JavaScript Code (.ts, .tsx, .js, .jsx files)\n\n**Style Guide**: Follow Prettier configuration (`.prettierrc`)\n- **Quotes**: Single quotes preferred\n- **Semicolons**: Required\n- **Trailing commas**: Always include\n- **Indentation**: 2 spaces\n- **Bracket spacing**: No spaces (`{foo}` not `{ foo }`)\n\n```typescript\n// Good TypeScript style\nexport interface WindowsSpecificProps {\n acceptsKeyboardFocus?: boolean;\n accessibilityRole?: string;\n}\n\nexport const WindowsButton: React.FC = ({\n acceptsKeyboardFocus = true,\n accessibilityRole,\n children,\n}) => {\n return (\n \n {children}\n \n );\n};\n```\n\n**Key Patterns**:\n- Use TypeScript for type safety\n- Export interfaces for public APIs\n- Prefer functional components with hooks\n- Use React Native core components as base\n\n## Development Workflow\n\n### Building and Testing\n\n```bash\n# Install dependencies\nyarn install\n\n# Build all packages\nyarn build\n\n# Run linting\nyarn lint\n\n# Fix linting issues\nyarn lint:fix\n\n# Format C++ code\nyarn format\n\n# Run tests\nyarn test\n```\n\n### Making Changes\n\n1. **Create feature branch** from main\n2. **Make minimal changes** following existing patterns\n3. **Run linting and formatting** before committing\n4. **Add change files** using `yarn change` for versioning\n5. **Test thoroughly** including relevant test suites\n\n### Required Commands for Every PR\n\n**Always run these commands after making changes in PRs:**\n\n```bash\n# Fix linting issues automatically\nyarn lint:fix\n\n# Format C++ code according to project standards\nyarn format\n\n# Generate change files for versioning (prerelease for development)\nyarn change --type prerelease\n```\n\nThese commands ensure code quality, consistent formatting, and proper change tracking for the monorepo versioning system.\n\nDelete the PR branch \"colpilot/fix-*\" once the copilot PR is merged or closed to maintain repo hygiene.\n\n### Native Module Development\n\n**C++ Native Module Pattern**:\n```cpp\nREACT_MODULE(SampleModule)\nstruct SampleModule {\n REACT_INIT(Initialize)\n void Initialize(React::ReactContext const &reactContext) noexcept;\n \n REACT_METHOD(GetDeviceName)\n void GetDeviceName(React::ReactPromise promise) noexcept;\n \n REACT_EVENT(OnDataReceived)\n std::function OnDataReceived;\n};\n```\n\n**C# Native Module Pattern**:\n```csharp\n[ReactModule]\npublic sealed class SampleModule\n{\n [ReactMethod]\n public void GetDeviceName(IReactPromise promise)\n {\n promise.Resolve(Environment.MachineName);\n }\n \n [ReactEvent]\n public Action OnDataReceived { get; set; }\n}\n```\n\n## Common Patterns and Best Practices\n\n### Error Handling\n- Use `React::ReactPromise` for async operations that can fail\n- Throw `React::ReactError` for immediate failures\n- Log errors using `IReactContext::LogError()`\n\n### Memory Management\n- Use RAII and smart pointers in C++\n- Avoid circular references between C++ and JavaScript\n- Dispose of resources in component unmount/cleanup\n\n### Performance Considerations\n- Minimize cross-thread marshaling\n- Use batch updates for multiple property changes\n- Prefer native UI thread for UI operations\n- Cache expensive computations\n\n### Testing\n- Write unit tests for business logic\n- Use integration tests for React Native bridge interactions\n- Include accessibility testing\n- Test on both UWP and Win32 targets when applicable\n\n## Technology-Specific Guidelines\n\n### Windows Runtime (WinRT) Interop\n- Use `winrt::` namespace for Windows Runtime types\n- Handle exceptions from WinRT APIs appropriately\n- Use `co_await` for async WinRT operations\n\n### XAML Integration\n- Follow XAML naming conventions for dependency properties\n- Use data binding where appropriate\n- Handle XAML events on UI thread\n\n### Win32 Integration\n- Use Windows App SDK APIs for modern Win32 features\n- Handle Win32 messages appropriately\n- Consider DPI awareness for UI elements\n\n## File Organization\n\n- **Source files**: Place in appropriate package under `packages/` or `vnext/`\n- **Tests**: Co-locate with source or in dedicated test directories\n- **Documentation**: Add to `docs/` for public APIs\n- **Examples**: Include in sample applications when relevant\n\n## Comments and Documentation\n\n- Use JSDoc for TypeScript/JavaScript APIs\n- Document public C++ APIs with doxygen-style comments\n- Include usage examples for complex APIs\n- Explain Windows-specific behavior differences\n\nThis guidance helps ensure consistent, high-quality contributions to React Native Windows while leveraging platform-specific capabilities effectively.\n",".github/skills/rnw-integration/README.md":"# RNW Integration Skill\n\nAutomates upgrading React Native Windows to newer upstream React Native nightly builds.\n\n## What This Skill Does\n\nThis skill guides GitHub Copilot through the full RNW integration workflow — from finding the next nightly version to building and deploying the Playground app. It handles version updates, override upgrades, merge conflict resolution, and build validation.\n\n## Prerequisites\n\nBefore running this skill, ensure you have:\n\n- **Node.js** >= 22 installed\n- **Yarn** package manager (the repo uses Yarn Berry / v4)\n- **Visual Studio 2022** with:\n - C++ Desktop development workload\n - Windows App SDK\n - Windows 10/11 SDK\n- **Git** configured with access to:\n - Your RNW fork (origin)\n - `https://github.com/Microsoft/react-native-windows` (upstream)\n- **Developer Mode** enabled in Windows Settings (for app sideloading)\n\n## How to Use\n\n### Option 1: Run the Full Integration\n\nType in VS Code Copilot Chat:\n```\n/rnw-integration run all steps\n```\n\n### Option 2: Run Specific Steps\n\n```\n/rnw-integration run step 1 to 5\n/rnw-integration run step 11\n/rnw-integration run step 12\n```\n\n### Option 3: Just Find the Next Version\n\n```\n/rnw-integration find next nightly version\n```\n\n## Steps Overview\n\n| Step | Description | Automated? |\n|------|-------------|-----------|\n| 1-5 | Find current version, calculate target date, query npm | Yes |\n| 6 | Run `yarn integrate-rn ` | Yes |\n| 7 | Update remaining package.json files | Yes |\n| 8 | Clean node_modules and reinstall dependencies | Yes |\n| 9 | Run `npx react-native-platform-override upgrade` | Interactive |\n| 10 | Commit changes | Yes |\n| 11 | Replace failing overrides from upstream | Yes |\n| 12 | Resolve merge conflicts (human-in-the-loop) | Per-hunk approval |\n| 13 | Update yarn.lock, build Playground composition app | Yes (long build) |\n| 14 | Deploy and launch Playground | Yes |\n\n## Key Concepts\n\n### Nightly Versions\nReact Native publishes nightly builds with the format:\n```\n0.XX.0-nightly-YYYYMMDD-\n```\nRNW integrates every ~7 days by advancing to a newer nightly.\n\n### Overrides\nRNW maintains platform-specific copies of upstream files (`.windows.js`, `.win32.js`). The override system tracks which upstream files are copied and detects when they change.\n\n### Merge Conflicts\nWhen upstream changes conflict with RNW's Windows-specific modifications, conflicts appear as `<<<<<<< Upstream` / `>>>>>>> Override` markers. Step 11 resolves these with human approval.\n\n### Conflict Resolution Patterns\nHistorical patterns are documented in `references/conflict-patterns.md`. The skill uses these to propose resolutions with confidence levels (Low/Medium/High).\n\n## File Structure\n\n```\n.github/skills/rnw-integration/\n├── README.md # This file\n├── SKILL.md # Main skill instructions\n├── references/\n│ └── conflict-patterns.md # Historical conflict resolution patterns\n└── scripts/ # (future automation scripts)\n```\n\n## Common Issues\n\n### Build fails with \"Yarn packages are out of date\"\nRun `yarn install` in the repo root before building.\n\n### Build fails with missing Boost headers\nRun NuGet restore:\n```powershell\nmsbuild /t:Restore /p:Configuration=Debug /p:Platform=x64\n```\n\n### MSIX install fails with \"No signature was present\" (0x800B0100)\nDebug builds are not signed. Use loose layout registration instead:\n```powershell\nAdd-AppxPackage -Register \\AppxManifest.xml -ForceApplicationShutdown\n```\n\n### MSBuild file locking errors (midl.exe)\nA previous build process is still running. Clean the build directory:\n```powershell\nRemove-Item -Recurse -Force vnext\\build -ErrorAction SilentlyContinue\n```\n\n### Override validation fails after integration\nRun Step 10 to replace failing overrides from upstream, then Step 11 to resolve remaining conflicts.\n\n## Tips\n\n- The build (Step 12) takes 15-30 minutes for a clean build\n- When resolving conflicts, respond \"Yes to all remaining\" if all hunks are High confidence\n- Always check the upstream compare URL before accepting conflict resolutions\n- The major version (e.g., 0.84 → 0.85) may change between nightlies\n",".github/skills/rnw-integration/SKILL.md":"---\nname: rnw-integration\ndescription: 'Automate React Native Windows integration with upstream React Native nightly versions. Use when: upgrading RNW to a newer React Native nightly, finding target nightly versions, preparing integration PRs, updating package dependencies.'\nargument-hint: 'Describe the integration task (e.g., \"find next nightly version\")'\n---\n\n# RNW Integration Automation\n\nAutomates the process of integrating React Native Windows with upstream React Native nightly builds.\n\n## When to Use\n\n- Finding the target React Native nightly version for integration\n- Upgrading RNW dependencies to a new React Native nightly\n- Preparing integration pull requests\n- Validating nightly version availability on npm\n\n## Procedure\n\n### Step 1: Get Current React Native Version\n\nExtract the current `react-native` version from `vnext/package.json`:\n\n```powershell\n$packageJson = Get-Content -Path \"vnext/package.json\" | ConvertFrom-Json\n$currentVersion = $packageJson.devDependencies.'react-native'\nWrite-Host \"Current version: $currentVersion\"\n```\n\nExpected format: `0.XX.0-nightly-YYYYMMDD-`\n\nAfter completing this step, confirm: **Step 1 completed successfully.**\n\n### Step 2: Parse the Current Version Date\n\nExtract the date from the nightly version string:\n\n```powershell\n# Parse version like: 0.84.0-nightly-20260107-58bc6c3e3\n$versionMatch = $currentVersion -match 'nightly-(\\d{8})'\n$currentDate = [DateTime]::ParseExact($matches[1], 'yyyyMMdd', $null)\nWrite-Host \"Current nightly date: $($currentDate.ToString('yyyy-MM-dd'))\"\n```\n\nAfter completing this step, confirm: **Step 2 completed successfully.**\n\n### Step 3: Calculate Target Date (+7 days)\n\n```powershell\n$targetDate = $currentDate.AddDays(7)\n$targetDateStr = $targetDate.ToString('yyyyMMdd')\nWrite-Host \"Target date (+7 days): $($targetDate.ToString('yyyy-MM-dd'))\"\n```\n\nAfter completing this step, confirm: **Step 3 completed successfully.**\n\n### Step 4: Find Nightly Version on npm\n\nQuery npm for available nightly versions around the target date:\n\n```powershell\n# Get all nightly versions for the target month\n$yearMonth = $targetDate.ToString('yyyyMM')\n$nightlyVersions = npm view react-native versions --json 2>$null | \n ConvertFrom-Json | \n Where-Object { $_ -like \"*nightly-$yearMonth*\" }\n\n# Find exact match or next available\n$targetVersion = $nightlyVersions | Where-Object { $_ -like \"*nightly-$targetDateStr*\" } | Select-Object -First 1\n\nif (-not $targetVersion) {\n Write-Host \"No nightly for $targetDateStr, finding next available...\"\n $targetVersion = $nightlyVersions | Where-Object { \n $_ -match 'nightly-(\\d{8})' -and [int]$matches[1] -gt [int]$targetDateStr \n } | Select-Object -First 1\n}\n\nWrite-Host \"Target nightly version: $targetVersion\"\n```\n\nAfter completing this step, confirm: **Step 4 completed successfully.**\n\n### Step 5: Output Summary\n\n```powershell\nWrite-Host \"\"\nWrite-Host \"=== Integration Summary ===\"\nWrite-Host \"Current Version: $currentVersion\"\nWrite-Host \"Current Date: $($currentDate.ToString('yyyy-MM-dd'))\"\nWrite-Host \"Target Date: $($targetDate.ToString('yyyy-MM-dd'))\"\nWrite-Host \"Target Version: $targetVersion\"\n```\n\nAfter completing this step, confirm: **Step 5 completed successfully.**\n\n### Step 6: Run Integration Script\n\nRun the integration script with the target nightly version to update all dependencies:\n\n```powershell\nyarn integrate-rn $targetVersion\n```\n\nThis command updates all `react-native` and `@react-native/*` package references across the monorepo to the target nightly version.\n\nAfter completing this step, confirm: **Step 6 completed successfully.**\n\n### Step 7: Search and Update Remaining package.json Files\n\nAfter running the integration script, search all `package.json` files for any remaining references to the previous nightly version and update them:\n\n```powershell\n# Find all package.json files containing the previous nightly version\n$packageFiles = Get-ChildItem -Path . -Filter \"package.json\" -Recurse -File | \n Where-Object { $_.FullName -notlike \"*node_modules*\" }\n\n$updatedFiles = @()\n\nforeach ($file in $packageFiles) {\n $content = Get-Content -Path $file.FullName -Raw\n if ($content -like \"*$currentVersion*\") {\n Write-Host \"Found previous version in: $($file.FullName)\"\n $newContent = $content -replace [regex]::Escape($currentVersion), $targetVersion\n Set-Content -Path $file.FullName -Value $newContent -NoNewline\n $updatedFiles += $file.FullName\n }\n}\n\nWrite-Host \"\"\nWrite-Host \"=== Updated $($updatedFiles.Count) package.json files ===\"\n$updatedFiles | ForEach-Object { Write-Host \" - $_\" }\n```\n\nThis ensures all references to the previous nightly version are updated, including:\n- `dependencies`\n- `devDependencies`\n- `peerDependencies`\n- `resolutions`\n\nAfter completing this step, confirm: **Step 7 completed successfully.**\n\n### Step 8: Clean node_modules and Reinstall Dependencies\n\nAfter updating all package.json files, remove all `node_modules` directories across the repo and perform a fresh install to ensure the dependency tree is consistent with the new versions:\n\n```powershell\n# Delete all node_modules directories (excluding .git)\nGet-ChildItem -Path . -Directory -Filter \"node_modules\" -Recurse |\n Where-Object { $_.FullName -notlike \"*.git*\" } |\n ForEach-Object {\n Write-Host \"Removing: $($_.FullName)\"\n Remove-Item -Recurse -Force $_.FullName\n }\n\nWrite-Host \"All node_modules directories removed.\"\n```\n\nThen run a fresh install at the root of the repo:\n\n```powershell\nyarn install\n```\n\nIf `yarn install` fails (e.g., due to peer dependency mismatches or build script errors), diagnose and fix the issue:\n- **Peer dependency warnings**: These are typically non-blocking in Yarn 4. Check if the install actually completed.\n- **Build script failures**: Check the build log path shown in the error output. Common issues include missing type declarations or renamed modules — fix the source files causing the build error and re-run `yarn install`.\n- **Resolution conflicts**: If a resolution in the root `package.json` still points to an old version, update it to the target nightly version.\n\nAfter completing this step, confirm: **Step 8 completed successfully.**\n\n### Step 9: Upgrade Platform Overrides\n\nRun the override upgrade tool to resolve conflicts in platform-specific override files:\n\n```powershell\nnpx react-native-platform-override upgrade\n```\n\nThis interactive tool helps resolve conflicts between upstream React Native changes and RNW platform overrides. It will:\n- Show files with merge conflicts\n- Allow you to accept upstream changes, keep local changes, or manually merge\n- Update the overrides.json manifest files\n\nAfter completing the upgrade, verify the overrides are valid:\n\n```powershell\nyarn validate-overrides\n```\n\nAfter completing this step, confirm: **Step 9 completed successfully.**\n\n### Step 10: Commit All Changes\n\nAfter completing all integration steps, commit the changes:\n\n```powershell\ngit add -A\ngit commit -m \"Integrate RN $targetVersion\"\n```\n\nThis creates a single commit with all the integration changes including:\n- Updated package.json dependencies\n- Override file upgrades\n- Any auto-fixed lint issues\n\nAfter completing this step, confirm: **Step 10 completed successfully.**\n\n### Step 11: Update Failing Overrides from Upstream\n\nRun `yarn validate-overrides` to identify which folders need to be replaced with upstream versions, then download and replace them:\n\n```powershell\n# Extract commit hash from target version (last 8 characters after final hyphen)\n# Example: 0.85.0-nightly-20260114-f15985f4f -> f15985f4f\n$commitHash = ($targetVersion -split '-')[-1]\nWrite-Host \"Commit hash: $commitHash\"\n\n# Run validate-overrides and capture failing paths\n$validateOutput = yarn validate-overrides 2>&1\n$failingPaths = $validateOutput | Where-Object { $_ -match '^ - ' } | ForEach-Object { $_.Trim(' -') }\n\nif ($failingPaths.Count -eq 0) {\n Write-Host \"No failing overrides to update\"\n return\n}\n\nWrite-Host \"Found $($failingPaths.Count) failing override paths to update\"\n\n# Create temp directory (outside git tracking)\n$tempDir = \"$env:TEMP\\rn-upstream-$commitHash\"\nif (Test-Path $tempDir) { Remove-Item -Recurse -Force $tempDir }\nNew-Item -ItemType Directory -Path $tempDir | Out-Null\n\n# Download react-native repo at the specific commit\nWrite-Host \"Downloading react-native at commit $commitHash...\"\ngit clone --depth 1 --filter=blob:none --sparse https://github.com/facebook/react-native.git $tempDir\nPush-Location $tempDir\ngit sparse-checkout set packages/rn-tester\ngit fetch --unshallow\ngit checkout $commitHash\nPop-Location\n\n# Replace each failing path with upstream version\nforeach ($path in $failingPaths) {\n # Convert absolute path to relative\n $relativePath = $path -replace [regex]::Escape((Get-Location).Path + '\\'), ''\n \n # Map RNW paths to upstream rn-tester paths\n $upstreamPath = $null\n \n if ($relativePath -like \"packages\\@react-native\\tester\\*\") {\n # packages\\@react-native\\tester\\X -> packages\\rn-tester\\X\n $subPath = $relativePath -replace '^packages\\\\@react-native\\\\tester\\\\', ''\n $upstreamPath = \"$tempDir\\packages\\rn-tester\\$subPath\"\n }\n elseif ($relativePath -like \"vnext\\ReactCopies\\*\") {\n # vnext\\ReactCopies\\X -> packages\\rn-tester\\X\n $subPath = $relativePath -replace '^vnext\\\\ReactCopies\\\\', ''\n $upstreamPath = \"$tempDir\\packages\\rn-tester\\$subPath\"\n }\n \n if ($upstreamPath -and (Test-Path $upstreamPath)) {\n Write-Host \"Replacing $relativePath with upstream version...\"\n Remove-Item -Recurse -Force $relativePath\n Copy-Item -Recurse -Force $upstreamPath $relativePath\n } else {\n Write-Host \"WARNING: Could not find upstream path for $relativePath\"\n }\n}\n\n# Cleanup temp directory\nRemove-Item -Recurse -Force $tempDir\nWrite-Host \"Overrides updated from upstream commit $commitHash\"\n```\n\nVerify the overrides are valid after the update:\n\n```powershell\nyarn validate-overrides\n```\n\nAfter completing this step, confirm: **Step 11 completed successfully.**\n\n### Step 12: Resolve Merge Conflicts (Human-in-the-Loop)\n\nAfter Steps 9-11, some override files may still contain merge conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`). This step resolves them safely with human approval for each hunk.\n\n**NON-NEGOTIABLE CONSTRAINTS:**\n- Conflicts are handled hunk-by-hunk (each `<<<<<<<` ... `=======` ... `>>>>>>>` region is one hunk)\n- HUMAN-IN-THE-LOOP: Do NOT apply any change automatically — ask for explicit approval for EACH hunk\n- Safety exceptions:\n - Some `>>>>>>>` markers are intentional (e.g., E2E `react-native-platform-override` files) — do not \"fix\" those\n - Leave conflicts in `flowconfig.windows.conflict` untouched\n\n#### Phase 1 — Build RNW Conflict-Resolution Knowledge Base\n\nBefore resolving any conflicts, mine historical \"good\" RNW-fork commits for conflict-resolution patterns. Create or update [references/conflict-patterns.md](./references/conflict-patterns.md).\n\nReference commits to study:\n```\nceeaddc0d19161e4fa0e01139a721b758d0269ce\n9f26c15efab7b51dd8544f50d2a26905bb875223\n1d7f44c4ad58a3ffa506cdc618c92d0dcebaf238\ne5d505e43d47a7cc603cd1be3d875dc0e3ab6ab9\n3e3b133fcb32f39f485b075858eaa7ff55d0d912\n9b40dac70b27ec2e5c3d0449bca50c841764e413\nd73784caa0d7e91a6c20fa485cf9ccb7923a1d40\nb6315a67451f9a2526ba1a5f3814d4ca6564342c\nbb50808b9f7e63da8af5511bf4b2faf064add19f\n```\n\nFor each commit:\n- Identify files where merge conflicts were resolved\n- Extract BEFORE/AFTER snippets for each resolved hunk (summarise if large)\n- Categorise into reusable patterns (name + signals + anti-signals)\n- Include example references (commit + file path + short diff summary)\n- Include safety notes: intentional markers, flowconfig rule, E2E override markers\n\n#### Phase 2 — Discover Conflicts and Split into Hunks\n\nScan the repository for conflict markers:\n\n```powershell\n# Find all files with conflict markers (excluding node_modules, intentional files)\n$conflictFiles = Get-ChildItem -Path . -Recurse -File |\n Where-Object { $_.FullName -notlike \"*node_modules*\" -and $_.Name -ne \"flowconfig.windows.conflict\" } |\n ForEach-Object {\n $content = Get-Content -Path $_.FullName -Raw -ErrorAction SilentlyContinue\n if ($content -match '<<<<<<<') { $_.FullName }\n }\n\nWrite-Host \"=== Files with conflict markers ===\"\n$conflictFiles | ForEach-Object { Write-Host \" - $_\" }\nWrite-Host \"Total: $($conflictFiles.Count) files\"\n```\n\nSplit each conflicted file into individual hunks for review.\n\n#### Phase 3 — Propose Resolution (Pattern-First, No Auto-Apply)\n\n**IMPORTANT: Guard against \"previously-intentionally-skipped\" upstream changes.**\n\nIn some prior RNW integrations, certain upstream changes were intentionally NOT taken for specific files (e.g., because RNW has a divergent Windows copy, platform overrides, or intentional conflict markers). In later integrations, those same upstream changes may reappear and must NOT be automatically accepted.\n\n**Before resolving any conflict hunk**, you MUST first inspect the actual upstream change using the compare URL:\n\n- **Compare URL format:** `https://github.com/facebook/react-native/compare/...`\n - LEFT = previous nightly version commit hash (from `$currentVersion`)\n - RIGHT = target nightly version commit hash (from `$targetVersion`)\n - Example: `https://github.com/facebook/react-native/compare/58bc6c3e3...f15985f4f`\n\n**Required steps for each hunk:**\n\n1. **Inspect upstream changes** via the compare URL:\n - Identify the exact files changed upstream\n - Determine what lines/sections changed and why (intent)\n2. **Compare against the RNW Windows-copy** of the file:\n - If the RNW file is a direct copy → upstream changes usually apply (unless conflict-patterns indicates otherwise)\n - If RNW contains Windows-only edits (often marked with `// [Windows`) or is substantially different → upstream changes may be intentionally NOT applicable\n3. **Check references/conflict-patterns.md** for a matching \"intentional skip / divergence\" pattern and apply that guidance first\n4. **Only THEN** propose a hunk resolution using the structured prompt system (merge prompt + file-type prompts + source-folder instructions) and run validation to output confidence (`Low`/`Medium`/`High`)\n5. **If the upstream change was intentionally skipped in a previous integration**, do NOT accept it automatically even if it reappears now:\n - Prefer the documented RNW pattern (\"skip/retain RNW version\") and explain the rationale\n - Set confidence to `Low` or `Medium` as appropriate and request human approval\n\n**Output requirement for each hunk proposal:**\n- The compare URL used\n- A 1-2 line summary of what upstream changed\n- Why we should or should not take it in RNW\n- Confidence level (`Low`/`Medium`/`High`)\n- Request for approval before applying\n\n**CRITICAL: Separate upstream changes — do NOT bundle unrelated changes into one resolution.**\n\nWhen the THEIRS (upstream) side contains MULTIPLE independent changes (e.g., a syntax rename `$ReadOnly` → `Readonly` AND a semantic change like adding `Omit<>`), treat each change independently:\n- Only apply the change that directly caused the conflict (usually the syntax/formatting change)\n- Do NOT silently adopt additional semantic changes (new props, `Omit<>`, added/removed parameters) from THEIRS unless they are explicitly part of the same conflict region AND you have confirmed via the compare URL that the semantic change is safe for RNW\n- If THEIRS has both a syntax change and a semantic change, propose ONLY the syntax change merged with OURS content, and separately flag the semantic change for review\n- When in doubt, keep OURS content and only apply the minimal syntax fix from THEIRS\n\nExample of what NOT to do:\n```\nTHEIRS: Readonly<{ ...Omit,\nOURS: $ReadOnly<{ ...ViewProps,\n\nWRONG resolution: Readonly<{ ...Omit, ← silently adopted Omit from upstream\nCORRECT resolution: Readonly<{ ...ViewProps, ← only took the syntax change, kept OURS content\n```\n\n**CRITICAL: Line-by-line diff the OURS and THEIRS blocks before proposing.**\n\nBefore proposing any resolution, explicitly diff the OURS and THEIRS blocks line by line:\n1. Identify EVERY difference between OURS and THEIRS (not just the obvious one like `$ReadOnly` → `Readonly`)\n2. Classify each difference as either:\n - **Syntax-only** (e.g., `$ReadOnly` → `Readonly`, `$FlowFixMe[incompatible-return]` → `$FlowFixMe[incompatible-type]`) — safe to take from THEIRS\n - **Content addition in THEIRS** (e.g., new props, `Omit<>` additions, new parameters) — do NOT take unless confirmed safe\n - **Content in OURS not in THEIRS** (e.g., Windows-specific types, `// [Windows` blocks) — ALWAYS keep\n3. The proposed resolution MUST be: OURS content + only syntax-only fixes from THEIRS\n4. If OURS had no wrapper (e.g., `type Props = {` without `$ReadOnly`) and THEIRS adds one (`Readonly<{`), keep OURS as-is — do NOT add wrappers that OURS didn't have\n5. If OURS uses exact objects (`{||}`, `{|`) and THEIRS uses inexact (`{}`, `{`), keep OURS exact syntax\n\n---\n\nFor each hunk, generate a PROPOSAL:\n\n1. **Analysis**: Show OURS (RNW fork side) vs THEIRS (upstream side) with surrounding context\n2. **Pattern match**: Attempt to match against patterns in [references/conflict-patterns.md](./references/conflict-patterns.md)\n3. **Proposed merged output**: Apply merge prompt + file-type rules + folder-specific bias\n4. **Validation**: Judge correctness + risk, assign confidence: `Low` / `Medium` / `High`\n5. **Approval request** (REQUIRED for each hunk):\n - Present: file path, hunk index, \"what changed\" summary, confidence, exact replacement text\n - Ask: \"Approve applying this hunk? (Yes/No)\"\n - If No: propose alternative OR provide manual steps\n - If Low confidence: do NOT propose auto-application; provide manual-resolution plan instead\n\n#### Phase 3b — Present Detailed Per-Hunk Proposals\n\nAfter generating the batch summary table, present EACH hunk individually for review. For every hunk show:\n\n1. **Header**: File path, hunk index (e.g., \"Hunk 1/2\"), line numbers\n2. **OURS block**: The exact `=======` to `>>>>>>>` content (RNW Override side)\n3. **THEIRS block**: The exact `<<<<<<<` to `=======` content (Upstream side)\n4. **Surrounding context**: 3-5 lines before `<<<<<<<` and after `>>>>>>>`\n5. **Pattern matched**: Which pattern from `references/conflict-patterns.md` applies (P1-P7)\n6. **Compare URL**: The upstream compare link used\n7. **Upstream intent**: 1-2 line summary of what upstream changed and why\n8. **Proposed resolution**: The exact replacement text that would replace the entire conflict block (from `<<<<<<<` through `>>>>>>>` inclusive)\n9. **Confidence**: `Low` / `Medium` / `High`\n10. **Approval prompt**: \"Approve applying this hunk? (Yes/No)\"\n\nWait for the user's response before proceeding to the next hunk. If the user says:\n- **Yes**: Apply the replacement immediately, confirm, then show next hunk\n- **No**: Ask if they want an alternative proposal, manual steps, or to skip\n- **Skip**: Leave conflict markers in place, move to next hunk\n- **Yes to all remaining**: Apply all remaining hunks without further prompts (only if all are High confidence)\n\n**File-type specific rules:**\n- `.js`/`.ts`/`.tsx`: Preserve `// [Windows` sections; prefer upstream for pure formatting changes\n- `.cpp`/`.h`: Check for `#ifdef WINDOWS` / platform-specific guards; upstream-first for shared code\n- `.flowconfig`/config files: Keep RNW-specific entries, add new upstream entries\n- `package.json`: Use target nightly version for all RN-related deps\n\n**Folder-specific bias:**\n- `vnext/src-win/`: Bias toward RNW (OURS) — these are Windows-specific overrides\n- `packages/@office-iss/`: Bias toward RNW (OURS) — Win32-specific\n- `packages/@react-native/tester/`: Bias toward upstream (THEIRS) — should match upstream\n- `vnext/ReactCopies/`: Bias toward upstream (THEIRS) — should be exact copies\n\n#### Phase 4 — Apply (Only After Per-Hunk Approval)\n\nAfter explicit approval for a hunk:\n- Replace the original conflict block with the validated \"Resolved Hunk\"\n- Never touch intentional markers (E2E platform override files)\n- Never remove the `flowconfig.windows.conflict` conflict\n\nAfter all hunks are resolved:\n\n```powershell\n# Verify no unintentional conflict markers remain\n$remaining = Get-ChildItem -Path . -Recurse -File |\n Where-Object { $_.FullName -notlike \"*node_modules*\" -and $_.Name -ne \"flowconfig.windows.conflict\" } |\n ForEach-Object {\n $content = Get-Content -Path $_.FullName -Raw -ErrorAction SilentlyContinue\n if ($content -match '<<<<<<<') { $_.FullName }\n }\n\nif ($remaining.Count -eq 0) {\n Write-Host \"All conflicts resolved!\"\n} else {\n Write-Host \"WARNING: $($remaining.Count) files still have conflict markers\"\n $remaining | ForEach-Object { Write-Host \" - $_\" }\n}\n\n# Commit resolved conflicts\ngit add -A\ngit commit -m \"Resolve merge conflicts for RN $targetVersion integration\"\n```\n\nAfter completing this step, confirm: **Step 12 completed successfully.**\n\n### Step 13: Post-Merge RNW Playground Validation (Mandatory)\n\nAfter resolving merge conflicts, perform an initial functional smoke check by building and running RNW Playground locally.\n\n#### Build and Run Playground\n\nFirst, ensure the yarn lockfile is up to date (upstream dependency changes during integration may have introduced new packages):\n\n```powershell\nyarn install\n```\n\nIf the lockfile changed, commit it before building:\n\n```powershell\ngit add yarn.lock\ngit diff --cached --quiet yarn.lock || git commit -m \"Update yarn.lock for RN $targetVersion integration\"\n```\n\nThen build the Playground:\n\n```powershell\n# Find MSBuild path\n$msbuild = & \"${env:ProgramFiles(x86)}\\Microsoft Visual Studio\\Installer\\vswhere.exe\" -latest -requires Microsoft.Component.MSBuild -find MSBuild\\**\\Bin\\MSBuild.exe\nWrite-Host \"MSBuild: $msbuild\"\n\n# Build the Playground composition via the solution (required for SolutionPath property)\n# Target only the playground-composition.Package project\n& $msbuild packages/playground/windows/playground-composition.sln /t:playground-composition_Package /p:Configuration=Debug /p:Platform=x64 /p:RestoreLockedMode=false /m\n\n# If build succeeds, launch the app to verify runtime behavior\n```\n\nThe solution file is at: `packages/playground/windows/playground-composition.sln`\nThe target project is: `playground-composition.Package` (built via `/t:playground-composition_Package`)\n\n#### If Playground Fails to Build or Run\n\nSome integration failures are caused by upstream changes that were previously fixed during earlier RNW integrations via patches applied in the RNW forked repository. The following commits contain known previous integration build/runtime fixes:\n\n```\n885aa5b51f1b4493a4bed16fce846270adb44d70\n01bfeefcb58a0688713c42b5c5b867319a25029e\n76a133e7ff81e148db6a9cd1d7d4c7a7aca86cb6\n477ea4915576235f82e2b6349917f345ce929180\n21285f1247cec3bb9667859c5698d10930eefd1b\n9a2e17697526ed219a33d96f7acf0903669f7585\naabe43e85e3e201ab99e0ac71ef6ee7dcf442110\n5a6fdb82771e9cbc6ee019dab5766f03761df6d0\n48e7a08931a59be27cc8709a511b7c6aea3d6900\n61392d901dd036b3abe456de1f5ace8571954811\n9fb535e0285883ba95b39018d26ff2ba7b876d53\ncf1e9188c391c0411205657bbdcd8feb5d851fc4\n```\n\n#### Recovery Workflow\n\nFor EACH commit listed above:\n\n1. **Inspect the commit** in the RNW forked repository:\n - Identify which files were changed\n - Determine what build/runtime issue the change addressed\n - Check whether the affected code paths exist in the current merged state\n\n2. **Validate relevance** BEFORE applying any change:\n - Confirm the same issue is occurring in the current Playground failure\n - Check if the fix is still relevant in the current upstream context\n - Validate the compare diff\n - Ensure the fix does not conflict with:\n - RNW Windows-specific adaptations\n - Intentionally skipped upstream changes\n - Entries documented in `references/conflict-patterns.md`\n\n3. **Prepare a FIX PROPOSAL and request approval:**\n\n Present:\n - Commit hash being considered\n - Files impacted\n - Short description of the original issue the fix addressed\n - Why this fix is applicable to the current failure\n - Exact proposed patch/diff to apply\n - Confidence level (`Low` / `Medium` / `High`)\n\n Ask explicitly: **\"Approve applying this fix? (Yes/No)\"**\n\n4. **Apply ONLY after explicit approval.**\n\n If confidence is `Low`:\n - Do NOT apply automatically\n - Provide manual investigation guidance instead\n - Request further direction\n\n#### Recovery Log\n\nMaintain a recovery log for each evaluated commit:\n\n| Commit | Issue Matched | Confidence | Approval | Applied/Skipped |\n|--------|--------------|------------|----------|-----------------|\n| `885aa5b...` | (description) | High/Med/Low | Yes/No | Applied/Skipped |\n| ... | ... | ... | ... | ... |\n\nAfter all fixes are applied and Playground builds successfully:\n\n```powershell\ngit add -A\ngit commit -m \"Apply build fixes for RN $targetVersion integration\"\n```\n\nAfter completing this step, confirm: **Step 13 completed successfully.**\n\n### Step 14: Deploy and Launch Playground\n\nAfter the build succeeds, deploy and launch the Playground app to verify runtime behavior.\n\n**IMPORTANT: Debug builds are NOT signed.** Do NOT attempt to install via MSIX (`Add-AppxPackage -Path *.msix`) — it will fail with `0x800B0100: No signature was present`. Instead, use **loose layout registration** via `Add-AppxPackage -Register `, which does not require signing or certificates.\n\n```powershell\n# Register the app from the loose layout (no signing needed for debug builds)\n$appxManifest = \"packages\\playground\\windows\\playground-composition.Package\\bin\\x64\\Debug\\AppX\\AppxManifest.xml\"\n\nif (Test-Path $appxManifest) {\n Write-Host \"Registering app from: $appxManifest\"\n Add-AppxPackage -Register $appxManifest -ForceApplicationShutdown\n} else {\n # Fallback: search for AppxManifest.xml in build output\n $appxManifest = Get-ChildItem -Path \"packages\\playground\\windows\" -Filter \"AppxManifest.xml\" -Recurse -ErrorAction SilentlyContinue |\n Where-Object { $_.FullName -like \"*bin*Debug*AppX*\" } |\n Select-Object -First 1 -ExpandProperty FullName\n if ($appxManifest) {\n Write-Host \"Registering app from: $appxManifest\"\n Add-AppxPackage -Register $appxManifest -ForceApplicationShutdown\n } else {\n Write-Host \"ERROR: No AppxManifest.xml found. Build may have failed.\"\n }\n}\n\n# Launch the app\n$appPackage = Get-AppxPackage -Name \"*playground*\" | Select-Object -First 1\nif ($appPackage) {\n $appId = (Get-AppxPackageManifest $appPackage).Package.Applications.Application.Id\n $fullName = $appPackage.PackageFamilyName\n Write-Host \"Launching: $fullName!$appId\"\n Start-Process \"shell:AppsFolder\\$fullName!$appId\"\n Write-Host \"Playground launched successfully. Verify the app renders correctly.\"\n} else {\n Write-Host \"WARNING: Could not find installed Playground package. Try deploying from Visual Studio.\"\n}\n```\n\nAfter verifying the app launches and renders correctly:\n- Check that the main screen loads without crashes\n- Verify basic component rendering (text, buttons, views)\n- Check the debug console for any runtime errors\n\nAfter completing this step, confirm: **Step 14 completed successfully.**\n\n## Key Files to Update\n\nWhen integrating a new nightly version, these files typically need updates:\n\n| File | Dependencies to Update |\n|------|----------------------|\n| `vnext/package.json` | `react-native`, `@react-native/*` packages |\n| `package.json` (root) | `react-native` in resolutions |\n| Various app `package.json` files | Peer dependencies |\n\n## Notes\n\n- The major version (e.g., 0.84 → 0.85) may change between nightlies\n- Always verify the target version exists before updating dependencies\n",".github/skills/rnw-integration/references/conflict-patterns.md":"# RNW Conflict Resolution Patterns\n\nPatterns mined from historical integration commits for resolving merge conflicts in React Native Windows.\n\n## Pattern Categories\n\n### P1: Keep Both — Upstream + Windows Props/Lines\n\n**Signals:** Upstream adds a new prop/line, RNW has Windows-specific props adjacent. Both sides add non-overlapping content.\n\n**Resolution:** Keep BOTH the upstream line AND the RNW Windows-specific lines. Remove conflict markers only.\n\n**Example** (commit bb50808b9f — Image.windows.js):\n```\nBEFORE (conflict):\n 'aria-selected': ariaSelected,\n<<<<<<< Upstream\n 'aria-hidden': ariaHidden,\n=======\n 'aria-readonly': ariaReadOnly, // Windows\n 'aria-multiselectable': ariaMultiselectable, // Windows\n ...\n height,\n>>>>>>> Override\n\nAFTER (resolved):\n 'aria-selected': ariaSelected,\n 'aria-hidden': ariaHidden,\n 'aria-readonly': ariaReadOnly, // Windows\n 'aria-multiselectable': ariaMultiselectable, // Windows\n ...\n height,\n```\n\n**Example** (commit bb50808b9f — Text.windows.js):\n```\nBEFORE:\n<<<<<<< Upstream\n importantForAccessibility: _importantForAccessibility,\n=======\n // #[Windows\n accessibilityLevel: _accessibilityLevel,\n ...\n // #]Windows\n>>>>>>> Override\n\nAFTER:\n importantForAccessibility: _importantForAccessibility,\n // #[Windows\n accessibilityLevel: _accessibilityLevel,\n ...\n // #]Windows\n```\n\n---\n\n### P2: Keep Only RNW (OURS) — Platform-Specific Logic\n\n**Signals:** Upstream has platform-specific code (`spec.android`), RNW replaces with Windows equivalent (`spec.windows`). Upstream changed formatting/comments only.\n\n**Resolution:** Keep the RNW (Override) side. Apply upstream's comment/formatting fixes to the RNW version.\n\n**Example** (commit 3e3b133fcb — Platform.windows.js):\n```\nBEFORE:\n<<<<<<< Upstream\n 'android' in spec\n ? // $FlowFixMe[incompatible-type]\n spec.android\n=======\n 'windows' in spec\n ? // $FlowFixMe[incompatible-return]\n spec.windows\n>>>>>>> Override\n\nAFTER:\n 'windows' in spec\n ? // $FlowFixMe[incompatible-type] ← took upstream's comment fix\n spec.windows ← kept Windows platform\n```\n\n---\n\n### P3: Drop RNW Side — Upstream Supersedes\n\n**Signals:** Upstream added functionality that makes the RNW-specific version redundant, or RNW side was a workaround that's no longer needed.\n\n**Resolution:** Keep the upstream (Upstream) side, remove the RNW override.\n\n**Example** (commit 3e3b133fcb — TextInput.windows.js):\n```\nBEFORE:\n<<<<<<< Upstream\n accessibilityLabel={_accessibilityLabel}\n=======\n accessibilityErrorMessage={accessibilityErrorMessage}\n>>>>>>> Override\n\nAFTER:\n accessibilityLabel={_accessibilityLabel}\n```\nHere the RNW-only prop `accessibilityErrorMessage` was replaced with the standard upstream `accessibilityLabel`.\n\n---\n\n### P4: Keep Only RNW (OURS) — Large Block Override\n\n**Signals:** Upstream has a complete component render block, RNW has a completely different render that uses `Platform.OS === 'windows'` branching. The upstream block is for Android/iOS only.\n\n**Resolution:** Delete the upstream block, keep the RNW `// [Windows` ... `// Windows]` block. Apply any upstream comment/annotation fixes.\n\n**Example** (commit 3e3b133fcb — Button.windows.js):\n```\nBEFORE:\n<<<<<<< Upstream\n return (\n ← Android/iOS render\n ...\n \n );\n=======\n // [Windows\n if (Platform.OS === 'windows') { ← Windows-specific render\n ...\n }\n // Windows]\n>>>>>>> Override\n\nAFTER:\n // [Windows\n if (Platform.OS === 'windows') {\n ... ← kept, with upstream annotation fixes applied\n }\n // Windows]\n```\n\n---\n\n### P5: Merge Union Types — Add Upstream Entry to RNW List\n\n**Signals:** Upstream adds a new entry to a union type or enum. RNW has its own entry. Both are valid.\n\n**Resolution:** Keep both entries. May need to adjust syntax (e.g., add `|` for union continuation).\n\n**Example** (commit ceeaddc0d1 — ViewAccessibility.windows.js):\n```\nBEFORE:\n | 'iconmenu'\n<<<<<<< Upstream\n | string;\n=======\n | 'listitem'; // RNW-only\n>>>>>>> Override\n\nAFTER:\n | 'iconmenu'\n | 'listitem' // RNW-only\n | string;\n```\n\n---\n\n### P6: Merge Object Properties — Keep Both Sides\n\n**Signals:** Upstream adds new properties to a type/interface, RNW adds different properties. Both are valid additions.\n\n**Resolution:** Keep both sets of properties, deduplicate, add proper separating comments.\n\n**Example** (commit 9f26c15efa — ViewPropTypes.win32.js):\n```\nBEFORE:\n<<<<<<< Upstream\n experimental_accessibilityOrder?: ?Array,\n=======\n accessibilityLabeledBy?: ?string, // Win32-only\n accessibilityControls?: ?string, // Win32-only\n>>>>>>> Override\n\nAFTER:\n experimental_accessibilityOrder?: ?Array,\n\n /** @platform win32 */\n accessibilityLabeledBy?: ?string,\n /** @platform win32 */\n accessibilityControls?: ?string,\n```\n\n---\n\n### P7: Package.json — Always Remove Conflict Markers\n\n**Signals:** package.json files with version conflicts from nightly version changes.\n\n**Resolution:** Remove all conflict markers, use the target nightly version. These should already be handled by Steps 6-7.\n\n---\n\n## Safety Rules\n\n### Intentional Markers — DO NOT RESOLVE\n- Files managed by `react-native-platform-override` E2E may contain `>>>>>>>` markers by design\n- `flowconfig.windows.conflict` files — leave all conflict markers in place\n\n### File-Type Rules\n| File type | Default bias |\n|-----------|-------------|\n| `.windows.js` in `vnext/src-win/` | Bias OURS (Windows override) |\n| `.win32.js` in `packages/@office-iss/` | Bias OURS (Win32 override) |\n| `packages/@react-native/tester/` | Bias THEIRS (should match upstream) |\n| `vnext/ReactCopies/` | Bias THEIRS (exact copies of upstream) |\n| `.cpp`, `.h` in `vnext/Microsoft.ReactNative/` | Bias OURS unless shared code |\n| `package.json` | Use target nightly version |\n\n### Marker Format\nThe override tool uses these marker labels:\n- `<<<<<<< Upstream` — upstream React Native code\n- `=======`\n- `>>>>>>> Override` — RNW fork code\n\n### Common Anti-Patterns to Avoid\n- Dropping `// [Windows` sections when taking upstream\n- Losing Windows-specific props when upstream adds new ones\n- Taking upstream platform-specific code (`spec.android`) instead of keeping Windows equivalent\n- Removing `$FlowFixMe` annotations that upstream updated\n","packages/@office-iss/react-native-win32/README.md":"# @office-iss/react-native-win32\n\n**Internal use only**\n\nTo better support some of our open source efforts, we are publishing this @office-iss/react-native-win32 JS package that office uses on win32. This is not a package that is generally consumable by other since it requires Office's UI framework which isn't open source. But it does allow some of our other cross platform efforts to be able to open source their work where previously its been unable to if Office win32 was one of the target platforms. This will enable projects such as our cross platform component libraries to be able to be published to open source.\n\n# Running react-native on win32.\n\nWe do have a solution for running react-native in a win32 app. You can run react-native-windows on win32 using Xaml Islands. We are working on expanding the set of supported Windows versions to broaden the support of that, and provide more samples of how to do that.","packages/@react-native-windows/automation-channel/README.md":"# @react-native-windows/automation-channel\n\n@react-native-windows/automation-channel adds support for remote procedure calls from a node client to react-native-windows server on the same machine.\n\n## Example\n\n_node app_\n```ts\nimport {waitForConnection} from '@react-native-windows/automation-channel'\n\nconst rpcConnection = await waitForConnection({port: 8305});\nconst result = await rpcConnection.invoke(\"add\", [2, 2])\n```\n\n_react-native-windows app_\n```c++\n#include \"winrt/AutomationChannel.Server.h\"\n\n// AutomationChannel::CommandHandler allows registering methods\nwinrt::AutomationChannel::CommandHandler handler();\n\n// Binding to a simple method\nhandler.BindOperation(\"add\", [](const JSonValue& params) noexcept {\n auto addends = params.GetArray();\n\n auto sum = 0;\n for (const auto& addend : addends) {\n sum += addend.GetNumber();\n }\n \n return JSonValue::CreateNumberValue(sum);\n});\n\n// Methods may be bound to IAsyncAction or IAsyncOperation\nhandler.BindAsyncAction(\"performAsyncOperation\", [](const JSonValue& params) noexcept -> IAsyncAction {\n co_await performLongOperation();\n});\n\n// Start server\nwinrt::AutomationChannel::Server rpcServer(handler);\nco_await rpcServer.ProcessAllClientRequests(8305, 50ms);\n```\n\n## Installing\n@react-native-windows/automation-channel supports [auto-linking](https://microsoft.github.io/react-native-windows/docs/native-modules-autolinking) to allow installation into react-native-windows applications.\n\n\n## Architecture\n**Reverse TCP server:** Traditional server/client roles are reversed, where the node client creates a TCP server to connect to. This helps to bypass restrictions on inbound loopback traffic to UWP apps. This low-effort solution allows bypassing the UWP AppContainer.\n\n### Alternative approaches\n- **Named pipe created inside AppContainer:** Node provides first-class support for named-pipes through `net.socket`. It is possible to create a named pipe from a UWP process which a Win32 process can then connect to, allowing traditional server/client roles. Doing this requires locating the resource local to the AppContainer, using an API like `GetAppContainerNamedObjectPath`. This likely requires FFI (with node-gyp) or native extenssions.\n- **Proxy to full-trust process** The RNW application could create a full-trust process which proxies from TCP to named-pipe internal to the AppContainer. This bypasses inbound loopback restrictions, but adds complexity of deploying a separate process, requires two IPC channels.\n\n### Protocol\n@react-native-windows/automation-channel uses a TCP channel, sending JSON messages across the wire prefixed with length. Messages themselves are conformant to the [JSON-RPC](https://en.wikipedia.org/wiki/JSON-RPC) version 2.0 protocol.\n","packages/@react-native-windows/automation-commands/README.md":"# @react-native-windows/automation-commands\n\n`@react-native-windows/automation-commands` provides built-in commands that may\nbe used with `@react-native-windows/automation-channel` to make it easier to\ntest your application.\n\n**This package is a work in progress**\n\n## Adding to your application\n\n**TBD**\n\n## Commands\n\n### dumpVisualTree\n\nThe `dumpVisualTree` command creates a JSON object corresponding to the XAML\ntree under a given testID. This can be used in conjunction with snapshot\ntesting to validate that your native UI looks how you could expect.\n\n```ts\nimport {dumpVisualTree} from '@react-native-windows/automation-commands';\n\ntest('Widget', async () => {\n const dump = await dumpVisualTree('widget-test-id');\n expect(dump).toMatchSnapshot();\n});\n```\n\n#### Options\n**TBD**","packages/@react-native-windows/automation/README.md":"# @react-native-windows/automation\n\n`@react-native-windows/automation` makes it easy to perform UI tests against\nyour `react-native-windows` application using Jest. \n\n**This package is a work in progress**\n\n## System Requirements\n\n`@react-native-windows/automation` relies on [WinAppDriver 1.2.1](https://github.com/microsoft/WinAppDriver/releases/tag/v1.2.1)\nor later to manipulate and inspect your application via [Windows UI Automation](https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-overview).\nThis is already installed in common CI environments like GitHub Actions or\nAzure Pipelines hosted images.\n\n## Configuring Jest\n\nFirst, ensure that `@react-native-windows/automation` is included as a\ndependency in your package:\n\n```json\n{\n \"devDependencies\": {\n \"@react-native-windows/automation\": \"\",\n }\n}\n```\n\nNext, edit your [Jest configuration](https://jestjs.io/docs/configuration) to\nuse `@react-native-windows/automation` as your test environment. Add the\nfollowing to your `jest.config.js` or `jest.config.ts` file:\n\n```js\nmodule.exports = {\n...\n // Set up the automation environment before running tests\n testEnvironment: '@react-native-windows/automation',\n\n // Only run a single test at a time\n maxWorkers: 1,\n\n // Set up @react-native-windows/automation specific options (see below)\n testEnvironmentOptions: {\n app: '',\n },\n};\n```\n\n## Environment Options\n\n`@react-native-windows/automation` is configured via the\n`testEnvironmentOptions` property in your Jest configuration. The following\noptions are valid:\n\n```js\ntestEnvironmentOptions: {\n // Required: Your application to launch, as either an AppX package identity,\n // or path to an .exe for an unpackaged application.\n app: 'Microsoft.WindowsAlarms',\n\n /**\n * Optional: Arguments to be passed to your application when launched\n */\n appArguments: '--bundle testBundle.js';\n\n // Optional: Explicit path to WinAppDriver. By default,\n // `@react-native-windows/automation` tries to use\n // \"%PROGRAMFILES(X86)%\\Windows Application Driver\\WinAppDriver.exe\"\n winAppDriverBin: 'D:\\\\WinAppDriver.exe',\n\n // Optional: Whether to break on app launch, before starting tests \n breakOnStart: false,\n\n // Optional: Options to be passed to WebDriverIO\n // See https://webdriver.io/docs/options/\n webdriverOptions: {\n // Port to use for WebDriver server (Default 4723)\n port: 4444\n\n // Level of logging verbosity: trace | debug | info | warn | error\n logLevel: 'error',\n\n // Default timeout for all waitFor* commands.\n waitforTimeout: 60000,\n\n // Default timeout in milliseconds for request\n connectionRetryTimeout: 90000,\n\n // Default request retries count\n connectionRetryCount: 10,\n },\n},\n```\n\n## Writing Tests\n\n`@react-native-windows/automation` exports an `app` member with functions to\nperform globally scoped WebDriver commands, such as locating an element or\nwaiting for a condition. Several strategies are present to locate an element,\nwith the reccomended being to use React Native's `testID` property.\n\nA located `AutomationElement` exposes methods to allow application interaction\nand introspection, such as clicking or typing.\n\n```js\nimport {app} from '@react-native-windows/automation';\n\nbeforeAll(async () => {\n const appHeader = await app.findElementByTestID('app-header');\n\n await app.waitUntil(async () => {\n const headerText = await appHeader.getText();\n return headerText.includes('Welcome');\n }) \n});\n\ntest('Type abc', async () => {\n const textInput = await app.findElementByTestID('textinput-field');\n await textInput.setValue('abc');\n expect(await textInput.getText()).toBe('abc');\n});\n```\n\n## Performing Additional Actions\n\n**WIP Not yet exposed**\n\nSometimes it is useful to exmaine or manipulate the application in ways that\nare not exposed to Windows UI Automation. An additional package,\n`@react-native-windows/automation-channel` can be included in your application\nas a native module to allow writing custom commands performed by your\napplication in-process. Some pre-built commands can be included using the\n`@react-native-windows/automation-commands` package.\n\n## Visual Comparison\n\n**WIP Not yet exposed**\n\nA common use-case of UI testing is to ensure your components look the way you\nexpect. Tools like [enzyme](https://github.com/enzymejs/enzyme) allow\ninspecting your React component tree, but are oblivious to the native UI tree.\n\n`@react-native-windows/automation-commands` exposes a `dumpVisualTree` command\nwhich creates a JSON object corresponding to the XAML tree under a given\ntestID. This can be used in conjunction with snapshot testing to validate\nnative component logic stays consistent.\n\n```js\nimport {dumpVisualTree} from '@react-native-windows/automation-commands';\n\ntest('Widget', async () => {\n const dump = await dumpVisualTree('widget-test-id');\n expect(dump).toMatchSnapshot();\n});\n```","packages/@react-native-windows/cli/README.md":"# @react-native-windows/cli\n\nCLI to build and run React Native for Windows apps.\n\n## `autolink-windows`\n\nThe `autolink-windows` CLI command is used to link the native code and build systems for a React Native for Windows app with any native community modules it uses.\n\n**Note:** Autolinking runs automatically as part of running the `run-windows` CLI command, unless the `--no-autolink` argument is used.\n\n### Usage\nRuns Windows-specific autolinking for your RNW project.\n \n```bat\nnpx @react-native-community/cli autolink-windows\n```\n### Options\n\nHere are the options that `npx @react-native-community/cli autolink-windows` takes:\n| Option | Input Type | Description |\n|-----------------------|------------|--------------------------------------------------|\n| `--logging` | boolean | Verbose output logging |\n| `--check` | boolean | Only check whether any autolinked files need to change |\n| `--sln` | string | Override the app solution file determined by 'npx @react-native-community/cli config', i.e. `windows\\myApp.sln` |\n| `--proj` | string | Override the app project file determined by 'npx @react-native-community/cli config', i.e. `windows\\myApp\\myApp.vcxproj` |\n| `--no-telemetry` | boolean | Disables sending telemetry that allows analysis of usage and failures of the react-native-windows CLI |\n| `-h`, `--help` | boolean | Display help for command |\n\n## `codegen-windows`\n\nThe `codegen-windows` CLI command is used to generate some necessary Windows-specific native code for native modules.\n\n### Usage\nRuns Windows-specific codegen for native modules.\n \n```bat\nnpx @react-native-community/cli codegen-windows\n```\n### Options\n\nHere are the options that `npx @react-native-community/cli codegen-windows` takes:\n| Option | Input Type | Description |\n|-----------------------|------------|--------------------------------------------------|\n| `--logging` | boolean | Verbose output logging |\n| `--check` | boolean | Only check whether any codegen files need to change |\n| `--no-telemetry` | boolean | Disables sending telemetry that allows analysis of usage and failures of the react-native-windows CLI |\n| `-h`, `--help` | boolean | Display help for command |\n\n## `init-windows`\n\nThe `init-windows` CLI command is used to initialize a new React Native for Windows project inside an existing React Native project. \n\n### Usage\nInitializes a new RNW project from a given template.\n \n```bat\nnpx @react-native-community/cli init-windows\n```\n### Options\n\nHere are the options that `npx @react-native-community/cli init-windows` takes:\n| Option | Input Type | Description |\n|-----------------------|------------|--------------------------------------------------|\n| `--logging` | boolean | Verbose output logging |\n| `--template` | string | Specify the template to use |\n| `--name` | string | The native project name. Defaults to the name property in `app.json` or `package.json` |\n| `--namespace` | string | The native project namespace, expressed using dots as separators, i.e. `Level1.Level2.Level3`. Defaults to the same as name |\n| `--overwrite` | boolean | Overwrite any existing files without prompting |\n| `--no-telemetry` | boolean | Disables sending telemetry that allows analysis of usage and failures of the react-native-windows CLI |\n| `-h`, `--help` | boolean | Display help for command |\n\n## `run-windows`\n\nThe `run-windows` CLI command is used to build and run React Native for Windows apps. \n\n### Usage\nBuilds your RNW app and starts it on a connected Windows desktop, emulator or device.\n \n```bat\nnpx @react-native-community/cli run-windows\n```\n### Options\n\n> **Note:** Remote Debugging was officially marked as [deprecated](https://github.com/react-native-community/discussions-and-proposals/discussions/734) in RN 0.73 and will be removed in a later release.\n\nHere are the options that `npx @react-native-community/cli run-windows` takes:\n| Option | Input Type | Description |\n|-----------------------|------------|--------------------------------------------------|\n| `--release` | boolean | Specifies a Release build |\n| `--root` | string | Override the root directory for the project which contains the `windows` folder |\n| `--arch` | string | The build architecture, i.e. `ARM64`, `x86`, `x64`. Defaults to system architecture |\n| `--singleproc` | boolean | Disables multi-proc build |\n| `--emulator` | boolean | Deploys the app to an emulator |\n| `--device` | boolean | Deploys the app to a connected device |\n| `--target` | string | Deploys the app to the specified `GUID` for a device |\n| `--logging` | boolean | Verbose output logging |\n| `--no-packager` | boolean | Do not launch the packager while building |\n| `--bundle` | boolean | Enable Bundle configuration, i.e. `ReleaseBundle`/`DebugBundle` rather than `Release`/`Debug` |\n| `--no-launch` | boolean | Do not launch the app after deployment |\n| `--no-autolink` | boolean | Do not run autolinking |\n| `--no-build` | boolean | Do not build the solution |\n| `--no-deploy` | boolean | Do not deploy the app |\n| `--deploy-from-layout`| boolean | Force deploy from layout even in Release builds |\n| `--sln` | string | Override the app solution file determined by 'npx @react-native-community/cli config', i.e. `windows\\myApp.sln` |\n| `--proj` | string | Override the app project file determined by 'npx @react-native-community/cli config', i.e. `windows\\myApp\\myApp.vcxproj` |\n| `--msbuildprops` | string | Comma separated props to pass to MSBuild, i.e. `prop1=value1,prop2=value2` |\n| `--buildLogDirectory` | string | Optional directory where MSBuild log files should be stored |\n| `--info` | boolean | Dump environment information |\n| `--direct-debugging` | number | Enable direct debugging on specified port |\n| `--no-telemetry` | boolean | Disables sending telemetry that allows analysis of usage and failures of the react-native-windows CLI |\n| `-h`, `--help` | boolean | Display help for command |\n| `--client-logs` | boolean | Enable plain text JavaScript log streaming for all connected apps |\n\n## Data Collection\nThe software may collect information about you and your use of the software and send it to Microsoft. Microsoft may use this information to provide services and improve our products and services. You may turn off the telemetry as described in the repository. There are also some features in the software that may enable you and Microsoft to collect data from users of your applications. If you use these features, you must comply with applicable law, including providing appropriate notices to users of your applications together with a copy of Microsoft's privacy statement. Our privacy statement is located at https://go.microsoft.com/fwlink/?LinkID=824704. You can learn more about data collection and use in the help documentation and our privacy statement. Your use of the software operates as your consent to these practices.\n\nThis data collection notice only applies to the process of running the react-native-windows CLI (i.e. the commands above).\n","packages/@react-native-windows/codegen/README.md":"# @react-native-windows/codegen\n\nGenerators for @react-native/codegen targeting react-native-windows\n\n## Usage\n\nComing soon..\n","packages/@react-native-windows/find-dotnet-tools/README.md":"# @react-native-windows/find-dotnet-tools\n\nHelpers to locate .NET-based tools (e.g. PowerShell) restored via `dotnet tool restore` or\navailable on PATH.\n\nUsed to resolve tool paths consistently across local development and CI\nenvironments.\n\n## Usage\n\nAdd the package as a dependency:\n\n```json\n{\n \"dependencies\": {\n \"@react-native-windows/find-dotnet-tools\": \"\"\n }\n}\n```\n\n### findPowerShell\n\nLocates a PowerShell executable by checking, in order:\n\n1. A `dotnet-tool`-restored copy of `pwsh.exe` (skipped in CI builds)\n2. `pwsh.exe` on the system PATH\n\nThrows an error if `pwsh.exe` cannot be found.\n\n```js\nimport {findPowerShell} from '@react-native-windows/find-dotnet-tools';\n\nconst pwsh = findPowerShell();\n// e.g. \"C:\\\\Users\\\\user\\\\.nuget\\\\packages\\\\PowerShell\\\\7.6.1\\\\tools\\\\net10.0\\\\any\\\\win\\\\pwsh.exe\"\n```\n\n### getNugetGlobalPackagesFolder\n\nReturns the path to the global NuGet packages folder by checking, in order:\n\n1. The `NUGET_PACKAGES` environment variable\n2. The output of `dotnet nuget locals global-packages --list`\n3. The default `~/.nuget/packages` location\n\n```js\nimport {getNugetGlobalPackagesFolder} from '@react-native-windows/find-dotnet-tools';\n\nconst packagesDir = getNugetGlobalPackagesFolder();\n// e.g. \"C:\\\\Users\\\\user\\\\.nuget\\\\packages\"\n```\n","packages/@react-native-windows/fs/README.md":"# @react-native-windows/fs\n\n`@react-native-windows/fs` is a minimal-dependency drop-in replacement to `fs` with changes for\nresiliency, promises, and convenience. It has several opinionated changes, targeted towards CLI\napplications handling JavaScript-oriented files.\n\n![Usage Thumbnail](./assets/logo.png)\n\n## Async Usage (Default)\n\n`@react-native-windows/fs` exposes a Promise-based API, mostly matching that of `fs.promises`, with\nseveral methods added [extra methods](#Extra-Methods).\n\n```ts\n// import {promises as fs} from 'fs'\nimport fs from '@react-native-windows/fs';\n\nconst fileContent = await fs.readFile('foo.txt');\n```\n\n## Sync Usage\n\n`@react-native-windows/fs` exports all `fs.*Sync` Where an async version has a graceful\nimplementation, and the synchronous version does not, the method is marked as deprecated.\n\n```ts\n// import fs from 'fs'\nimport fs from '@react-native-windows/fs';\n\nconst fileContent = fs.readFileSync('foo.txt');\n```\n\n## Extra Methods\n\n### `exists`\nNodeJS deprecated `fs.exists`, and removed `fs.promises.exists`. The recommendation is to instead\nacquire a lock to the file via `fs.open` for the duration of file-use. One-shot existence checks are\nstill useful, and because `fs.existsSync`is not deprecated, more likely means usage of blocking\nsynchronous APIs.\n\n```ts\nimport fs from '@react-native-windows/fs';\n\nconst fooExists = await fs.exists('foo.txt');\n```\n\n### `readJsonFile` and `readJsonFileSync`\n\n`@react-native-windows/fs` provides convenience methods to handle JSON files. The following methods\nare added:\n\n| Method | Return type |\n|-|-|\n| `readJsonFile` | `Promise` or `Promise>` |\n| `readJsonFileSync` | `T` or `Record` |\n\n```ts\nimport fs from '@react-native-windows/fs';\n\n// foo is type: Record by default\nconst foo = await fs.readJsonFile('foo.json');\n\n// foo is type: FooProps\ntype FooProps = { name: string, version: string };\nconst foo = await fs.readJsonFile('foo.json');\n```\n\n## Resiliency\n\n`@react-native-windows/fs` uses [`graceful-fs`](https://github.com/isaacs/node-graceful-fs) to\ngracefully handle transient filesystem conditions, at the cost of extra latency. This includes\ntransient `EPERM`, `EACCESS`, `EMFILE`, `ENFILE`. This can be important when handling files that a\nsubject to antivirus, which may temporarily lock mutation of files on Windows.\n\n## eslint\nWe reccomend adding the following rules to your eslint config if you would like to use\n`@react-native-windows/fs` everywhere:\n```js\nmodule.exports = {\n rules: {\n 'no-restricted-imports': [\n 'error', {\n name: 'fs',\n message: 'Please use `@react-native-windows/fs` instead of `fs`'\n }\n ],\n }\n}\n```\n","packages/@react-native-windows/perf-testing/README.md":"# @react-native-windows/perf-testing\n\nPerformance testing utilities for React Native Windows components.\n\n## Overview\n\nThis package provides infrastructure for measuring and tracking performance of React Native components. It enables:\n\n- **Automated performance regression detection** on every PR\n- **Component-wise performance baselines** (mount, unmount, re-render times)\n- **Lightweight perf snapshots** similar to Jest snapshots\n- **Easy extensibility** for new components via base classes\n\n## Installation\n\n```bash\nnpm install @react-native-windows/perf-testing --save-dev\n# or\nyarn add @react-native-windows/perf-testing --dev\n```\n\n## Quick Start\n\n### 1. Create a Performance Test\n\n```typescript\nimport { ComponentPerfTestBase, IScenario } from '@react-native-windows/perf-testing';\nimport { View } from 'react-native';\n\nclass ViewPerfTest extends ComponentPerfTestBase {\n readonly componentName = 'View';\n readonly category = 'core' as const;\n readonly testId = 'perf-test-view';\n\n createComponent(props?: Record) {\n return ;\n }\n\n getCustomScenarios(): IScenario[] {\n return [\n {\n name: 'nested-views',\n description: 'Test nested views performance',\n run: () => this.measureNestedViews(50),\n },\n ];\n }\n}\n```\n\n### 2. Write Tests\n\n```typescript\nconst viewPerfTest = new ViewPerfTest();\n\ndescribe('View Performance', () => {\n test('mount time', async () => {\n const perf = await viewPerfTest.measureMount();\n expect(perf).toMatchPerfSnapshot();\n });\n\n test('rerender time', async () => {\n const perf = await viewPerfTest.measureRerender();\n expect(perf).toMatchPerfSnapshot();\n });\n});\n```\n\n### 3. Run Tests\n\n```bash\n# Run perf tests\nyarn perf\n\n# Update baselines\nyarn perf:update\n```\n\n## API Reference\n\n### Core Functions\n\n| Function | Description |\n|----------|-------------|\n| `measurePerf(component, options)` | Core measurement function |\n| `toMatchPerfSnapshot(threshold?)` | Jest matcher for perf snapshots |\n\n### Base Classes\n\n| Class | Description |\n|-------|-------------|\n| `ComponentPerfTestBase` | Abstract base class for component perf tests |\n\n### Interfaces\n\n| Interface | Description |\n|-----------|-------------|\n| `PerfMetrics` | Measurement results |\n| `PerfThreshold` | Pass/fail thresholds |\n| `IComponentPerfTest` | Contract for component tests |\n| `IScenario` | Custom scenario interface |\n\n### Threshold Presets\n\n```typescript\nimport { ThresholdPresets } from '@react-native-windows/perf-testing';\n\n// Available presets\nThresholdPresets.core // 10% regression threshold\nThresholdPresets.list // 15% for list components\nThresholdPresets.interactive // 20% for animated components\nThresholdPresets.community // 25% relaxed threshold for external use\n```\n\n## Extending for Custom Components\n\nCommunity developers can create perf tests for their custom native components:\n\n```typescript\nimport { ComponentPerfTestBase } from '@react-native-windows/perf-testing';\nimport { MyCustomSlider } from 'my-custom-component';\n\nclass MyCustomSliderPerfTest extends ComponentPerfTestBase {\n readonly componentName = 'MyCustomSlider';\n readonly category = 'custom' as const;\n readonly testId = 'perf-test-slider';\n\n createComponent(props?: Record) {\n return ;\n }\n}\n```\n\n## Configuration\n\n### Jest Setup\n\nAdd to your Jest setup file:\n\n```typescript\nimport '@react-native-windows/perf-testing/matchers';\n```\n\n### Custom Thresholds\n\n```typescript\nexpect(perf).toMatchPerfSnapshot({\n maxDurationIncrease: 15, // Allow 15% regression\n maxRenderCount: 5,\n});\n```\n\n## License\n\nMIT\n","packages/@react-native-windows/telemetry/README.md":"# @react-native-windows/telemetry\n\nTelemetry library for the react-native-windows CLI\n\n## Usage\n\n## Data Collection\nThe software may collect information about you and your use of the software and send it to Microsoft. Microsoft may use this information to provide services and improve our products and services. You may turn off the telemetry as described in the repository. There are also some features in the software that may enable you and Microsoft to collect data from users of your applications. If you use these features, you must comply with applicable law, including providing appropriate notices to users of your applications together with a copy of Microsoft's privacy statement. Our privacy statement is located at https://go.microsoft.com/fwlink/?LinkID=824704. You can learn more about data collection and use in the help documentation and our privacy statement. Your use of the software operates as your consent to these practices.\n","packages/@react-native/tester/js/examples/Experimental/PlatformTest/README.md":"# RNTester PlatformTest\n\nA barebones manual testing framework designed to work as a mechanism for recreating [Web Platform Tests](https://github.com/web-platform-tests/wpt) in React Native in order to verify their compliance with W3C specifications.\n\n## Usage\n\nAny new test case will start as a new React component which at the very least accepts a `harness` prop which will contain all of the framework's testing APIs. This component you write will be passed into the `component` prop of a `RNTesterPlatformTest` element whose other props are used for documenting your test. Rendering this `RNTesterPlatformTest` will look similar to something like this:\n\n```js\nfunction ExampleTestCase ({ harness }) { /* ... */ }\n\n\n```\n\n\nAs of writing this README there are 2 different types of tests that the `harness` prop provides:\n\n### `test(testcase: (TestContext) => void, testName: string, options?: TestOptions)`\n\nThis is a method to create \"regular\" test reminiscent of other frameworks such as Jest. These are meant to be run imperatively, and while that means that they technically could work in a `useEffect` hook as a way to run the test \"on mount\" — it is instead recommended to try and keep these tests in callbacks instead. A good alternative to running the test on mount would be to instead put the test in a callback and render a \"Start Test\" button which executes the callback.\n\nThe first argument is the closure in which you will run your test and make assertions. The assertions are contained in the `TestContext` object which is provided in the test closure's first argument and contains the following assertions:\n\n* `assert_true(a: boolean, description: string): void`\n* `assert_equals(a: any, b: any, description: string): void`\n* `assert_greater_than_equal(a: number, b: number, description: string): void`\n* `assert_less_than_equal(a: number, b: number, description: string): void`\n\nAn optional third argument can be used for specifying additional options to the test — that object currently has the following properties (all of which are optional themselves):\n\n* `skip: boolean`: In cases where we want the test to be registered but we don't want it to contribute to the pass/fail count.\n\nHere's what a basic/contrived example which verifies the layout of a basic view:\n\n```js\nconst EXPECTED_WIDTH = 100;\nconst EXPECTED_HEIGHT = 200;\n\nfunction BasicLayoutTestCase({harness}) {\n const viewRef = useRef(null);\n\n const runTest = useCallback(() => {\n const view = viewRef.current;\n if (view != null) {\n view.measureInWindow(({width, height}) => {\n harness.test(({assert_equals}) => {\n assert_equals(\n width,\n EXPECTED_WIDTH,\n `view's computed width should be ${EXPECTED_WIDTH}`,\n );\n assert_equals(\n height,\n EXPECTED_HEIGHT,\n `view's computed width should be ${EXPECTED_HEIGHT}`,\n );\n }, \"view's width and height are correct\");\n });\n }\n }, [harness]);\n\n return (\n <>\n \n