Split test_general into stable and experimental targets
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 45/100
- Tipo de issue
- Refatoração
- Clareza
- Razoavelmente clara
- Status de atividade
- Estagnada
- Stack de tecnologia
- c, javascript, node.js
- Domínio
- api, build-system, testing-qa
Direção de pesquisa
Comece pelo diretório upstream test/js-native-api/test_general e seu binding.gyp e, em seguida, compare como o CTS atualmente faz o port do único target experimental. Identifique os agrupamentos de funcionalidades stable e experimental descritos no issue. Considera-se concluído quando os testes da API stable puderem ser carregados sem todos os símbolos experimentais, enquanto os testes experimentais continuarem protegidos separadamente e puderem ser compilados.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
Problem
The upstream test_general test in the Node.js repository compiles a single target with NAPI_EXPERIMENTAL, which links against all experimental Node-API symbols (node_api_set_prototype, node_api_post_finalizer). This means the addon cannot be loaded on runtimes that don't export every experimental symbol.
In the CTS, this forces all test_general JS test files to guard loadAddon behind a check for every experimental feature the addon links against. The result is that even stable API tests (like napi_strict_equals, napi_typeof, napi_instanceof, etc.) are silently skipped on runtimes that don't support all experimental features.
Proposed solution
Split the upstream test_general into separate targets:
- Stable target — compiles without
NAPI_EXPERIMENTAL, includes all stable API functions - Experimental target(s) — one per experimental feature, compiled with the appropriate
NAPI_EXPERIMENTALdefine
This would allow the CTS to test stable APIs independently of experimental feature support.
Current workaround
The CTS ports test_general as a single experimental addon (matching upstream), with all JS tests guarded behind experimentalFeatures.setPrototype && experimentalFeatures.postFinalizer.
References
- Upstream source: https://github.com/nodejs/node/tree/main/test/js-native-api/test_general
- Upstream
binding.gypdefinesNAPI_EXPERIMENTALon the single target
- Linguagem predominante
- C
- Estrelas
- 18
- Forks
- 12
- Métricas de merge de PRs
- Nenhum PR com merge em 30d
Preparar o ambiente
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de nodejs/node-api-cts
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
nodejs/node-api-cts#37 · 1 comentário ·
-
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 35/100
nodejs/node-api-cts#85 ·
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 48/100
nodejs/node-api-cts#84 ·
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 45/100
nodejs/node-api-cts#61 ·
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 35/100
nodejs/node-api-cts#35 · 1 reação ·
Todas as issues de nodejs/node-api-cts
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 90/100
BasedHardware/omi#19711 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 85/100
microsoft/ebpf-for-windows#5604 ·
Mantenedores costumam responder em até 3 dias
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
trezor/trezor-firmware#7985 ·
Mantenedores costumam responder em até 2 dias
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 84/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
Mantenedores costumam responder em até 2 dias