Feat/windows support - #1483
Draft
riteshshukla04 wants to merge 5 commits into
Draft
Conversation
The core headers compiled on iOS and Android only because libc++ and libstdc++
leak transitive includes; MSVC does not, so a large number of translation units
failed to compile on Windows with missing std symbols. Every header now includes
what it uses.
Also:
* guard the GCC-only diagnostic pragmas so MSVC does not see them
* treat `_DEBUG` as a debug configuration, which is what MSVC defines instead
of `DEBUG`
* hoist `PromiseTask` out of the function scope it was declared in
No behaviour changes - this is includes and preprocessor guards only.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Adds the Windows platform layer and the `NitroModules` TurboModule that installs
Nitro into the JS runtime, so `HybridObject<{ windows: "c++" }>` works on
react-native-windows.
* `NativeNitroModules` installs Nitro from a two-argument `REACT_INIT`, which
RNW dispatches through `AddJsiInitializer` on the JS thread. That is the
only JSI entry-point that still works under the New Architecture -
`ExecuteJsi`, `TryGetOrCreateContextRuntime` and `ReactContext::JSRuntime`
are deprecated there and either fail-fast in Debug or no-op in Release.
* `UIThreadDispatcher` backs `ThreadUtils`. Windows has no process-wide handle
to the UI thread queue the way `dispatch_get_main_queue()` and the main
`Looper` are, so it is taken from the `ReactContext` at install time.
`runSync` throws, because `IReactDispatcher` only exposes `Post`.
* `NitroLogger` writes to the debugger output window; Windows has no logcat.
* `NitroModules.vcxproj` builds a **StaticLibrary**. RNW gives every module
image its own `JsiAbiRuntime` wrapper, so Nitro in a separate DLL would see
a different `jsi::Runtime*` than the Hybrid Objects linked into the app,
while `JSICache`, `PropNameIDCache` and `Dispatcher` are keyed on the
runtime and `HybridObjectRegistry` has to be a single registry.
* `windows/include/NitroModules/` forwards the core headers so
`#include <NitroModules/HybridObject.hpp>` resolves the same way it does
through the CocoaPods module on iOS. `PublicIncludeDirectories` puts them on
the include path of every project that references this one.
* `ReactPackageProvider` registers the module explicitly rather than through
`AddAttributedModules`. The linker does not pull an object file out of a
static library unless one of its symbols is referenced, so the
`REACT_MODULE` registration would silently never run.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Teaches nitrogen the `windows` platform, so `HybridObject<{ windows: "c++" }>`
generates bindings and autolinking for react-native-windows. C++ is the only
supported language there - RNW has no Swift or Kotlin equivalent - and the C++
specs are already shared with iOS and Android, so an existing C++ Hybrid Object
usually needs nothing more than adding `windows: "c++"` to its platform spec.
Two files are generated per module:
* `<Module>+autolinking.props`, an MSBuild property sheet that adds every
generated source to the consuming `.vcxproj` and exposes the generated
headers through `PublicIncludeDirectories`. This is the Windows counterpart
of `+autolinking.cmake` on Android.
* `<Module>Autolinking.{hpp,cpp}`, an `IReactPackageProvider` that registers
the autolinked Hybrid Objects. iOS uses `+load` and Android uses
`JNI_OnLoad` to run registrations automatically; Windows has no such hook,
so the registrations run from a package provider that
`autolink-windows` wires into the app. Registration is guarded by
`std::call_once`, because a package provider can be created more than once
while `HybridObjectRegistry` is process-wide.
The `winrt::` namespace comes from `windows.windowsModuleName` in nitro.json and
falls back to `ios.iosModuleName`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Builds the Windows static library in Debug and Release on `windows-2022`, against react-native-windows 0.84.0 / react-native 0.84.1 installed into a throwaway consumer package. NitroModules.vcxproj resolves react-native-windows by walking up to the nearest node_modules and needs jsi + ReactCommon headers to compile against; the monorepo cannot provide them, because its react-native is newer than any react-native-windows release. Debug builds with `/warnaserror:C4715,C4700` so uninitialised variables and missing returns fail the build rather than accumulating. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Adds a Windows guide covering installation, autolinking, the two app-side MSBuild settings an app needs (`CppWinRTGenerateWindowsMetadata` and `LanguageStandard`), how Nitro installs itself, and why it links statically. Also records what is not usable yet. Beyond Hybrid Views and worklets, two types are blocked on react-native-windows itself: `JsiAbiRuntime` crashes rather than throwing when a `bigint` is passed from JS into native, and when an `ArrayBuffer` created natively is returned to JS. Both work in the opposite direction. `setExternalMemoryPressure` is an empty body there, so GC pressure hints are ignored. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
@riteshshukla04 is attempting to deploy a commit to the Margelo Team on Vercel. A member of the Team first needs to authorize it. |
riteshshukla04
marked this pull request as draft
August 15, 2026 16:53
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
1 participant
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.
No description provided.