Fix napi_get_property_names conformance on JSC, ChakraCore and QuickJS

[bkaradzic-microsoft]

Fixes #216.

napi_get_property_names is specified to return the enumerable string-keyed properties of an object and of its prototype chain — the same set a for...in loop visits. Only the V8 backend did that. Every other backend diverged:

backend	enumerable-only	includes prototypes	works at all
V8	yes	yes	yes
JavaScriptCore	n/a	n/a	no — always threw
ChakraCore	no	no	yes
QuickJS	yes	no	yes
JSI	n/a	n/a	no — TODO stub

• JavaScriptCore called Object.getOwnPropertyNames with argc 0, so the object argument was never used and the call always threw TypeError: undefined is not an object.
• ChakraCore used JsGetOwnPropertyNames, which is own-only and also reports non-enumerable properties.
• QuickJS used JS_GetOwnPropertyNames with JS_GPN_ENUM_ONLY — enumerable-only, but still own-only.
• JSI (found while fixing the above) had Object::GetPropertyNames as an unimplemented stub that threw std::runtime_error{"TODO"}.

Approach

None of JSC, ChakraCore or QuickJS exposes a native equivalent of V8's kIncludePrototypes | ONLY_ENUMERABLE | SKIP_SYMBOLS key collection, so rather than write three subtly different prototype walks, this adds one shared implementation (Source/js_native_api_shared.{h,cc}) written purely against the public napi_* surface, and has all three delegate to it.

Per prototype level it takes:

• Object.keys — the properties for...in reports at that level, already in specification order;
• Object.getOwnPropertyNames — the shadowing set. A non-enumerable own property is not reported itself, but it does hide a same-named enumerable property further up the chain.

JSObjectCopyPropertyNames was considered for JavaScriptCore since it walks the chain natively, but it drops that shadowing rule, so the shared walk is used there too and all backends stay consistent. The input is coerced with napi_coerce_to_object, matching V8's CHECK_TO_OBJECT.

JSI keeps its own path: jsi::Object::getPropertyNames already has exactly the specified semantics, so Object::GetPropertyNames just forwards to it.

Two further bugs this uncovered

1. napi_get_prototype on JavaScriptCore (fixed here — the shared walk depends on it). It ran the result of JSObjectGetPrototype through JSValueToObject. At the top of a prototype chain that value is null, so the conversion threw TypeError: null is not an object instead of reporting the end of the chain, making the chain impossible to walk. It now returns the raw prototype value, as V8 does. It had no other callers in this repository — Blob.cpp deliberately uses Object.getPrototypeOf instead.

2. Hermes' for...in does not implement the shadowing rule (not fixed — engine bug). CI showed napi_get_property_names returning the correct ['own', 'middle'] while Hermes' own for...in returned ['own', 'middle', 'deep'], i.e. it reports an inherited property that a non-enumerable own property is supposed to hide. The test therefore probes for that behaviour at runtime rather than naming engines, and only uses for...in as an oracle where it holds; the explicit expected-value assertion still runs everywhere. Happy to file this separately if useful.

Testing

Nine script tests, exercised through a new napiGetPropertyNames global that calls Napi::Object::GetPropertyNames:

• own enumerable string keys
• enumerable properties inherited from the prototype chain
• non-enumerable own properties excluded
• symbol keys excluded
• a shadowed inherited property reported only once
• an inherited property shadowed by a non-enumerable own property omitted
• class methods excluded (they are non-enumerable)
• array indices as strings, length omitted
• equality with for...in over a multi-level prototype chain

Verified locally on ChakraCore, QuickJS and JSI — 225 passing, 0 failing on each. JavaScriptCore, V8 and Hermes are covered by CI; all 25 legs are green.

As a negative control, restoring the old ChakraCore implementation makes five of the nine fail, confirming the tests are load-bearing rather than vacuous:

napi_get_property_names (#216)
  ✅ returns own enumerable string keys
  1) includes enumerable properties inherited from the prototype chain
  2) excludes non-enumerable own properties
  ✅ excludes symbol keys
  ✅ reports a shadowed inherited property only once
  3) omits an inherited property shadowed by a non-enumerable own property
  ✅ excludes class methods, which are non-enumerable
  4) reports array indices as strings and omits the non-enumerable length
  5) matches for...in over a multi-level prototype chain

Note on scope

napi_get_all_property_names is still only implemented by the V8 backend; the others would fail to link if a consumer called it. That is a separate gap and is left alone here.

[Copilot]

Pull request overview

This PR aligns napi_get_property_names behavior across the JavaScriptCore, ChakraCore, and QuickJS backends to match the Node-API/V8 semantics: enumerable, string-keyed property names including the prototype chain (i.e., matching for...in, including the “non-enumerable own property shadows inherited enumerable” rule).

Changes:

• Added an engine-agnostic implementation (napi_shared::GetEnumerablePropertyNames) that walks the prototype chain using Object.keys plus Object.getOwnPropertyNames to enforce for...in-equivalent semantics.
• Updated JavaScriptCore, ChakraCore, and QuickJS napi_get_property_names implementations to delegate to the shared helper (and added missing CHECK_ARG(env, object) on JSC/Chakra).
• Added script-level regression tests and a test harness global (napiGetPropertyNames) to validate behavior against for...in.

Reviewed changes

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

Show a summary per file

File	Description
Tests/UnitTests/Shared/Shared.cpp	Exposes napiGetPropertyNames to script tests via the C++ harness.
Tests/UnitTests/Scripts/tests.ts	Adds regression tests for napi_get_property_names semantics (prototype chain, enumerability, symbols, shadowing, arrays).
Core/Node-API/Source/js_native_api_shared.h	Declares shared helper for napi_get_property_names semantics.
Core/Node-API/Source/js_native_api_shared.cc	Implements the shared prototype-chain walk using only public napi_* APIs.
Core/Node-API/Source/js_native_api_quickjs.cc	Replaces own-only QuickJS implementation with shared helper.
Core/Node-API/Source/js_native_api_javascriptcore.cc	Fixes JSC implementation (previously throwing) by delegating to shared helper and validating object.
Core/Node-API/Source/js_native_api_chakra.cc	Replaces own-only / non-enumerable-including Chakra implementation with shared helper and validates object.
Core/Node-API/CMakeLists.txt	Adds shared helper sources to non-V8 backend builds.

---

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

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (4)

Core/Node-API/Source/js_native_api_chakra.cc:688

• napi_shared::GetEnumerablePropertyNames can return napi_object_expected (for null/undefined) without setting env->last_error. Since CHECK_NAPI assumes last_error is already set, callers may observe stale napi_get_last_error_info data. Set last_error explicitly for this status before returning it.

  // `JsGetOwnPropertyNames` is own-only and includes non-enumerable properties,
  // so use the shared prototype-chain walk instead.
  CHECK_NAPI(napi_shared::GetEnumerablePropertyNames(env, object, result));

Core/Node-API/Source/js_native_api_javascriptcore.cc:976

• napi_shared::GetEnumerablePropertyNames can return napi_object_expected (for null/undefined) without setting env->last_error. Because CHECK_NAPI assumes last_error was already set, this can leave stale last-error info visible via napi_get_last_error_info when an error is returned. Set last_error explicitly for this status before returning.

  // JavaScriptCore's `JSObjectCopyPropertyNames` walks the prototype chain but
  // silently drops properties shadowed by a non-enumerable own property, so use
  // the shared prototype-chain walk instead.
  CHECK_NAPI(napi_shared::GetEnumerablePropertyNames(env, object, result));

  return napi_ok;

Tests/UnitTests/Shared/Shared.cpp:142

• When napi_get_property_names fails with a pending JavaScript exception, the current code clears and discards the original exception and instead throws a generic status-based error. This makes debugging failures harder and can hide the real engine error. If an exception is pending, rethrow that exception value instead of discarding it.

                    // A failed call may or may not have left a JavaScript
                    // exception pending; surface either as a thrown error so
                    // that the script tests can assert on it uniformly.
                    bool isExceptionPending{};
                    if (napi_is_exception_pending(rawEnv, &isExceptionPending) == napi_ok && isExceptionPending)
                    {
                        napi_value error{};
                        napi_get_and_clear_last_exception(rawEnv, &error);
                    }

Core/Node-API/Source/js_native_api_quickjs.cc:1403

• napi_shared::GetEnumerablePropertyNames can return napi_object_expected (for null/undefined) without setting env->last_error. Because CHECK_NAPI assumes the callee already set last_error, this can leave stale last-error info visible via napi_get_last_error_info even though the API returned an error. Handle this status explicitly and set last_error before returning it.

  // `JS_GetOwnPropertyNames` is own-only, so use the shared prototype-chain
  // walk instead.
  CHECK_NAPI(napi_shared::GetEnumerablePropertyNames(env, object, result));

  napi_clear_last_error(env);