feat(windows): build through the shared Nitro host (@padosoft/react-native-nitro-windows)

[47PADO47]

Stacked on #24 (the Kit split), which is stacked on #23.

Summary

React Native Windows now goes through the shared Nitro host, @padosoft/react-native-nitro-windows. It replaces this package's own Windows DLL (windows/Ecr17, which installed Nitro itself). The host's install, header-shim and platform code started from this repo's #23.

Why: Nitro must exist once per app. With one DLL per package, two Nitro packages in the same Windows app would each provide NitroModules and their own copy of Nitro's registry.

What changes

• package.json → nitroWindows: the binding's C++ (HybridEcr17Client, the adapter, the Windows transport), nitrogen's specs, registerEcr17HybridObjects(), and kits: ["@padosoft/ecr17-kit"]. The Kit declares its own nativeKit.windows sources (the core and WinsockTransport), and the host compiles each Kit once.
• windows/Ecr17Windows.{hpp,cpp}: the registration function, i.e. the job of the old Ecr17Module.
• Removed, now in the host: the DLL project, Ecr17.sln, the props and NuGet files, scripts/windows-nitro-shims.mjs, the platform hooks, and windows-autolink.js.
• react-native.config.js: windows: null.
• WinsockTransport.cpp: links ws2_32 with #pragma comment, because the host links nothing extra.
• example-windows:
  • depends on the host;
  • react-native.config.js uses the host's windowsAppDependencies();
  • AutolinkedNativeModules.g.* and the .sln point at NitroWindows.vcxproj. I edited these by hand to match what autolink-windows generates, using the host's GUID and WinRT namespace. Re-running npx react-native autolink-windows should give the same result.

⚠️ The host is not published yet

example-windows links it from a react-native-support checkout next to this repo:

"@padosoft/react-native-nitro-windows": "file:../../react-native-support/packages/react-native-nitro-windows"

Until padosoft/react-native-support#115 merges, that checkout needs the feat/nitro-windows-host branch. Once the host is published, switch to a version range. The READMEs and docs-site say this where they mention the host.

Changeset

Minor. Windows support (#23) was never released, so replacing windows-autolink with the host's helper breaks no published API.

Verification

• ✅ The host's module collector (collect-modules.mjs), run on macOS against a simulated app with these manifests, produces:
  • the package and the Kit's sources (each once, plus WinsockTransport);
  • the include directories;
  • registerNitroWindowsModules() calling margelo::nitro::ecr17::registerEcr17HybridObjects().
• ✅ The rest of the binding's C++ was already compile-checked and built for iOS in feat(kit): extract the protocol into @padosoft/ecr17-kit and adopt @padosoft/native-modules #24.
• ⏳ Windows, to run on a Windows machine:
  1. cmake -S kit -B build-win && cmake --build build-win --config Release && ctest --test-dir build-win -C Release --output-on-failure
  2. cd example-windows && npm install && npx react-native run-windows --arch x64 (with react-native-support cloned next to this repo)
  3. The runtime smoke test from AGENTS.md (fake terminal: connect, status frame, drop detected).

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying react-native-ecr17-protocol with    Cloudflare Pages

Latest commit:	a825f73
Status:	✅  Deploy successful!
Preview URL:	https://16cee7d0.react-native-ecr17-protocol.pages.dev
Branch Preview URL:	https://feat-ecr17-windows-nitro-hos.react-native-ecr17-protocol.pages.dev

View logs