Drop the host's shadowing implementations of runtime Node-API functions

[kraenhansen]

Summary

Hermes' first-party Node-API (adopted in #372, wired up via hermes_napi_host in #398) already implements the entire runtime surface, including buffers, napi_fatal_error, napi_get_version and napi_get_node_version. But packages/host/cpp/RuntimeNodeApi.{cpp,hpp} still defined eight of these — and won, because the generated injector (packages/host/scripts/generate-injector.mts) resolves each NodeApiHost field by unqualified name inside namespace callstack::react_native_node_api, and RuntimeNodeApi.hpp is included there. So unqualified lookup found the host's shim before it ever reached Hermes' exported symbol.

This PR removes seven of those eight functions, letting the unqualified-name lookup fall through to Hermes' own implementations (the same mechanism every other Node-API function in this codebase already relies on — RuntimeNodeApi.cpp itself calls napi_create_arraybuffer, napi_typeof, etc. without defining them, and those already resolve to Hermes today):

• napi_create_buffer, napi_create_buffer_copy, napi_create_external_buffer, napi_get_buffer_info, napi_is_buffer — dropped.
• napi_get_version — dropped (Hermes' answer is identical, NAPI_VERSION).
• napi_get_node_version — dropped. Closes Implement napi_get_node_version #67: addons now get Hermes' actual version instead of napi_generic_failure.
• napi_fatal_error — kept, with a comment on the declaration explaining why: Hermes routes it to stderr, which isn't logcat on Android, while the host's version reaches logcat via the NodeApiHost logger tag.

This also removes two bugs the shims carried:

1. napi_get_buffer_info overwrote a mutable global (ArrayType) used by napi_create_buffer/napi_create_external_buffer; calling it on a non-Uint8Array typed array (e.g. Float64Array) corrupted every later buffer creation on that process, and raced across runtimes.
2. napi_create_buffer_copy accepted result_data but never wrote it.

napi_is_buffer/napi_get_buffer_info also become stricter, matching Node: true/napi_ok only for Uint8Array, napi_invalid_arg otherwise (previously any ArrayBuffer/TypedArray). This is an intentional, documented behavior change (see the changeset), and also tightens #171.

RuntimeNodeApi.{cpp,hpp} keep their own translation unit rather than folding into Logger-adjacent code — the file now holds exactly the one shim the host deliberately keeps shadowing, and renaming would touch the generated injector, CMakeLists.txt, and the podspec's glob for no functional benefit. packages/host/android/CMakeLists.txt needed no changes as a result.

A changeset (patch) documents the observable behavior change for napi_get_node_version and the buffer functions.

Why this is safe (reachability of Hermes' symbols)

I verified, source-level, that removing the host's declarations doesn't strand these calls:

• The generated injector's NodeApiHost { .name = name, ... } entries are produced for every Node-API function from node-api-headers (packages/weak-node-api/src/node-api-functions.ts), regardless of whether the host defines it — this list is unaffected by this change.
• RuntimeNodeApi.cpp already calls many Node-API functions (napi_create_arraybuffer, napi_typeof, napi_is_arraybuffer, napi_get_arraybuffer_info, napi_get_typedarray_info, napi_create_external_arraybuffer) without defining them anywhere in this repo — those already resolve, at link time, to Hermes' exported symbols today. Once RuntimeNodeApi.hpp no longer declares the seven removed functions inside namespace callstack::react_native_node_api, unqualified lookup for them falls through to the same global-namespace declarations from node_api.h (already used identically for the calls above) and links against Hermes' hermesvm/xcframework the same way.

Verified

• pnpm install && pnpm run build — passes.
• pnpm --filter react-native-node-api run test — passes except three pre-existing, unrelated failures in path-utils.test.ts around unreadable-file/permission handling; confirmed those fail identically on unmodified origin/next in this sandbox (it runs as root, which bypasses the permission checks the tests rely on).
• pnpm exec eslint packages/host and pnpm exec prettier --check on touched files — clean.
• Checked no other files in the repo reference the removed functions or RuntimeNodeApi symbols outside the two edited files.

Not verified (needs a real device/toolchain)

• Native C++ compilation — no Android/iOS toolchain is available in this sandbox. The change was reviewed at the source level only.
• packages/node-addon-examples/tests/buffers still passing on device — reviewed the test source (addon.c/addon.js) against both the old and new (Hermes) semantics; every buffer the test creates goes through napi_create_buffer/napi_create_external_buffer (producing real Uint8Arrays under both implementations), and its one non-buffer check (invalidObjectAsBuffer) passes NULL for both data/length, which trips napi_invalid_arg under either implementation. So this should still pass, but this checklist item from Drop the host's shadowing implementations of runtime Node-API functions #428 remains pending human/CI verification on an actual device.

Closes #428, closes #67.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01DaK9eAAF5G8wj6UT8VekAm

---

Generated by Claude Code

[kraenhansen]

Swapped the host label (deleted) for Host 🏡, and pushed a fix for a real bug this surfaced: host-cpp-tests in .github/workflows/check.yml was checking for a label literally named host, which never matched the actual Host 🏡 label used everywhere else in the repo — so that job has only ever run on pushes to main/next, never via a labeled PR, until now.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01DaK9eAAF5G8wj6UT8VekAm

---

Generated by Claude Code