Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#84 0 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Pouca atividade
Stack de tecnologia
bun, javascript, node.js
Domínio
testing-qa

Direção de pesquisa

Comece pelos pontos de asserção em test_constructor/test.js, test_properties/test.js e test_bigint/test.js e, em seguida, execute esses testes no Bun ou em outro runtime que não seja V8. Confirme a direção preferida pelo maintainer para lidar com mensagens específicas do engine; considera-se concluído quando os testes verificam o comportamento indicado sem exigir a redação exata do V8 e passam nos runtimes relevantes.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
C
Estrelas
18
Forks
12
Nenhum PR com merge em 30d

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de nodejs/node-api-cts

Todas as issues de nodejs/node-api-cts

Issues semelhantes

Mais issues de C

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.