Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Some tests assert V8's exact error message wording, so non-V8 runtimes fail on prose

未關閉
  • 哪裡不對？
#84 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
48/100
Issue 類型
缺陷
描述清晰度
基本清楚
活躍度
冷清
技術堆疊
bun, javascript, node.js
領域
testing-qa

研究方向

先從 test_constructor/test.js、test_properties/test.js 和 test_bigint/test.js 中的斷言位置開始，然後在 Bun 或其他非 V8 runtime 下執行這些測試。確認 maintainer 對處理引擎特定訊息所偏好的方向；完成的標準是，測試在不要求 V8 的確切措辭的情況下驗證所述行為，並在相關 runtime 中通過。

由索引模型根據 Issue 內容生成。

描述

To see how far a non-V8 runtime gets, I ran the suite under Bun 1.3.14 (JavaScriptCore)
on Linux, with the addons rebuilt with GCC and the tests spawned the same way the node
implementor does. 43 of the 48 test files pass. Of the five failures, two are genuine
Node-API gaps in Bun (zero length external strings and Float16Array in the typed array
APIs, both since fixed on Bun's main branch). The other three fail only because the test
compares the thrown error's message text against V8's exact wording, and JavaScriptCore
words the same conditions differently. The same three files fail identically on Windows
with MSVC-built addons, which is where the quoted output below comes from.

The affected assertions:

test expects JSC actually throws
test_constructor/test.js line 15 /^TypeError: Cannot assign to read only property 'readonlyValue' of object '#<MyObject>'$/ TypeError: Attempted to assign to readonly property.
test_constructor/test.js lines 38, 42 /^TypeError: Cannot set property .* of #<.*> which has only a getter$/ TypeError: Attempted to assign to readonly property.
test_properties/test.js line 16 /^TypeError: Cannot assign to read only property '.*' of object '#<Object>'$/ TypeError: Attempted to assign to readonly property.
test_properties/test.js lines 55, 59 /^TypeError: Cannot set property .* of #<Object> which has only a getter$/ TypeError: Attempted to assign to readonly property.
test_bigint/test.js line 46 { name: 'RangeError', message: 'Maximum BigInt size exceeded' } RangeError: Out of memory

Three files, seven assertion sites, and it comes down to two JSC strings. Each run stops
at its first failing assertion, so the later sites in each file were confirmed by
evaluating the same operations directly under Bun in strict mode; JSC uses the single
Attempted to assign to readonly property. message for both the read only data property
and the getter-only accessor cases.

A representative failure from the run:

AssertionError: The input did not match the regular expression /^TypeError: Cannot assign to read only property 'readonlyValue' of object '#<MyObject>'$/. Input:

'TypeError: Attempted to assign to readonly property.'

and for the BigInt case:

Comparison {
+   message: 'Out of memory',
-   message: 'Maximum BigInt size exceeded',
    name: 'RangeError'
  }

What these assertions actually verify is real Node-API behavior: that
napi_define_properties produced a property that rejects writes with a TypeError, and
that the engine's own RangeError from an oversized BigInt propagates out of
napi_create_bigint_words as the pending exception. That part holds in Bun. The message
text on top of it is engine identity rather than conformance, and every non-V8 engine
(JSC here, Hermes and SpiderMonkey elsewhere) words it its own way, so as written a
conformant runtime scores red on strings it cannot change. The regexes came along
naturally with the ports from nodejs/node, where a single-engine assumption was fine.

A few possible directions, and I would rather follow your preference than pick one:

  1. Assert the error type and the behavior (the write throws and does not take effect,
    the BigInt call throws a RangeError) and drop the message text entirely.
  2. Keep a message assertion but loosen it to a shape every engine can meet, for example
    just /TypeError/, or name plus a much weaker pattern.
  3. Keep exact messages but make the expected strings per implementor, in the same spirit
    as features.js already being per implementor.

Happy to send a PR for whichever direction you want, or none if you would rather handle
it differently.

主要語言
C
星號
18
分支
12
30 天內沒有已合併 PR

環境準備

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

nodejs/node-api-cts 的其他 Issue

查看 nodejs/node-api-cts 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。