Split test_general into stable and experimental targets

Offen

#34 erstellt am 08.3.2026 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit: 4/5
Geschätzter Aufwand: 3-5 Tage
Anfängerfreundlichkeit: 45/100

Issue-Typ: Refactoring
Klarheit: Größtenteils klar
Aktivitätsstatus: Veraltet
Tech-Stack: c, javascript, node.js
Bereich: api, build-system, testing-qa

Rechercherichtung

Beginne mit dem Verzeichnis upstream test/js-native-api/test_general und seiner binding.gyp und vergleiche anschließend, wie CTS derzeit das einzelne experimentelle Target portiert. Identifiziere die im Issue beschriebenen Gruppierungen der stabilen und experimentellen Features. Als erledigt gilt die Aufgabe, wenn stabile API-Tests ohne alle experimentellen Symbole geladen werden können, während experimentelle Tests weiterhin separat geschützt und buildbar bleiben.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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_EXPERIMENTAL define

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.gyp defines NAPI_EXPERIMENTAL on the single target

Vorherrschende Sprache: C
Sterne: 18
Forks: 12
PR-Merge-Kennzahlen: Keine gemergten PRs in 30 T.

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
Forken Sie das Repository und arbeiten Sie in einem Branch.
Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus nodejs/node-api-cts

Drop Node.js v20 from CI matrix Offen

Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100

nodejs/node-api-cts#37 · 1 Kommentar · Erstellt am 28.3.2026
Version-derived feature flags in the node implementor misfire on runtimes that report a fictional Node version Offen

Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100

nodejs/node-api-cts#85 · Erstellt am 13.8.2026
Some tests assert V8's exact error message wording, so non-V8 runtimes fail on prose Offen

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 48/100

nodejs/node-api-cts#84 · Erstellt am 13.8.2026
Port SharedArrayBuffer TypedArray test Offen

Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 45/100

nodejs/node-api-cts#61 · Erstellt am 15.5.2026
Setup CI for publishing of the package Offen

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100

nodejs/node-api-cts#35 · 1 Reaktion · Erstellt am 13.3.2026

Alle Issues in nodejs/node-api-cts