Split test_general into stable and experimental targets
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- c, javascript, node.js
- Domain
- api, build-system, testing-qa
Research direction
Start with the upstream test/js-native-api/test_general directory and its binding.gyp, then compare how the CTS currently ports the single experimental target. Identify the stable and experimental feature groupings described in the issue. Done means stable API tests can load without all experimental symbols, while experimental tests remain separately guarded and buildable.
Written by the indexing model from the issue text.
Description
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
- Dominant language
- C
- Stars
- 18
- Forks
- 12
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from nodejs/node-api-cts
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
nodejs/node-api-cts#37 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
nodejs/node-api-cts#85 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
nodejs/node-api-cts#84 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
nodejs/node-api-cts#61 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
nodejs/node-api-cts#35 · 1 reaction ·
All issues in nodejs/node-api-cts
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
kovidgoyal/kitty#10516 ·
-
libc
Difficulty 2/5 1-2 days Newbie friendliness 76/100
llvm/llvm-project#225506 · 1 comment ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Status: Waiting triage Type: Bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
nanoframework/Home#1857 ·
-
bug
Difficulty 2/5 Half a day Newbie friendliness 82/100