Fix Windows/UWP CI build (MSVC C4875 + JSI include path)

[matthargett]

Two pre-existing build-config fixes that unbreak the Win32/UWP CI; no functional changes. We hit these
while expanding N-API version support (cf. #116, #183) but they're independent of that work.

• MSVC C4875: a newer MSVC promotes the deprecated non-string-literal [[gsl::suppress]] argument
  (from the vendored GSL headers) to an error under /WX, breaking every Win32/UWP build. Suppress it.
• JSI include path: add the shared Core/Node-API/Include/Shared to the JSI napi target so
  napi.h can find <napi/js_native_api_types.h> (was failing with C1083).

---

Landing sequence

Inter-related N-API PRs; intended order (✅ done / ⏳ pending):

1. ⏳ Fix Windows/UWP CI build (MSVC C4875 + JSI include path) #185 — Fix Windows/UWP CI build (MSVC C4875 + JSI include path). Independent build/toolchain fix; lands first so CI is green under everything below. (fork twin build: fix pre-existing Windows/UWP CI build failures (MSVC C4875 + JSI include path) rebeckerspecialties/JsRuntimeHost#5 — 22/22 green) ← this PR
2. ⏳ Build napi as a shared library on Android #183 — Build napi as a shared library on Android (so in-process addons resolve napi_*).
3. ⏳ Add N-API compliance tests #116 — N-API compliance tests (the Android addons resolve napi_* via the shared libnapi.so from the step above).
4. ⏳ N-API v7 across runtimes (V8 / JSC / Chakra) — N-API v7 across runtimes (V8 / JavaScriptCore / Chakra) #189 (draft) — fork CI twin N-API v7 across runtimes (V8 / JavaScriptCore / Chakra) rebeckerspecialties/JsRuntimeHost#4, 22/22 green.

Motivating RFCs: rebeckerspecialties#6 (jsc-android → maintained JSC) · rebeckerspecialties#7 (WebWorker via N-API → Factotum into BabylonNative).

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Update CMake configuration to fix JSI Node-API builds by adding missing shared header include paths and to keep Windows CI green by suppressing a new MSVC warning coming from vendored GSL headers.

Changes:

• Add Core/Node-API/Include/Shared to the include path for the napi target in the Node-API-JSI build.
• Suppress MSVC warning C4875 globally to avoid warnings-as-errors failures on newer toolchains.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
Core/Node-API-JSI/CMakeLists.txt	Adds missing shared include directory so JSI builds can find js_native_api_types.h.
CMakeLists.txt	Adds MSVC compile option to suppress C4875 emitted by vendored GSL headers.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bghgary]

[Commented by Copilot on behalf of @bghgary]

Closing — both fixes have been overtaken.

C4875. Real when you filed this on June 5. GSL v4.2.2 added a stringizing branch guarded on _MSC_VER >= 1950, and arcana bumped to it on July 6 (fe41b17). A full local build of main with VS2026 (_MSC_VER 1951) is clean with /WX on the GSL consumers, and #222 moves CI to windows-2025-vs2026 green with no source changes.

JSI include path.Core/Node-API-JSI/Include/napi/napi.h carries its own copy of those types (// Copied from js_native_api_types.h) rather than including the shared header — at this PR's base as well as today. Every real include is under Core/Node-API/Source/. #116 adds Core/Node-API/Include/Shared itself, PRIVATE, on node_lite and each addon.

Node-API-JSI also has no C entry points — no NAPI_EXTERN, no napi_status functions — so exporting a C-ABI header from it advertises a surface that doesn't exist, turning a clear C1083 into unresolved externals.

#116's actual blocker isn't JSI-specific. add_node_api_module links napi only on Android and uses -undefined dynamic_lookup only on Apple, so on Windows the .node modules fail LNK2019 on napi_get_last_error_info and friends — Win32_x64_V8 identically to Win32_x64_JSI. Windows needs the equivalent of what #183 gives Android.

Tests/CMakeLists.txt also gates NodeApi on no engine. Those tests shouldn't run against Node-API-JSI unless they're scoped to the C++ layer, and even then expect rough edges: that backend is a hack — a C++ shim over JSI rather than a Node-API implementation — and the intent is to retire it once Hermes / React Native has native Node-API support. Conforming it to the C ABI would be work spent on something we want to delete.