Split test_general into stable and experimental targets
還沒有人認領這個 Issue。
評估
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 新手友好度
- 45/100
- Issue 類型
- 重構
- 描述清晰度
- 基本清楚
- 活躍度
- 停滯
- 技術堆疊
- c, javascript, node.js
- 領域
- api, build-system, testing-qa
研究方向
從 upstream test/js-native-api/test_general 目錄及其 binding.gyp 開始，然後比較 CTS 目前如何移植單一 experimental target。確認 issue 中描述的 stable 與 experimental feature 分組。完成的標準是：stable API tests 可以在不載入所有 experimental symbols 的情況下載入，而 experimental tests 仍然受到個別 guard 保護並且可以 build。
由索引模型根據 Issue 內容生成。
描述
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
- 主要語言
- C
- 星號
- 18
- 分支
- 12
- PR 合併指標
- 30 天內沒有已合併 PR
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
nodejs/node-api-cts 的其他 Issue
-
難度 2/5 1-3 小時 新手友好度 68/100
nodejs/node-api-cts#37 · 1 則留言 ·
-
難度 5/5 一週以上 新手友好度 35/100
nodejs/node-api-cts#85 ·
-
難度 4/5 3-5 天 新手友好度 48/100
nodejs/node-api-cts#84 ·
-
Port SharedArrayBuffer TypedArray test可能已有人在做 @hexbinoct 於 71 天前認領。 未關閉
難度 3/5 1-2 天 新手友好度 45/100
nodejs/node-api-cts#61 ·
-
難度 4/5 3-5 天 新手友好度 35/100
nodejs/node-api-cts#35 · 1 個 reaction ·
查看 nodejs/node-api-cts 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 84/100
ARM-software/CMSIS-DSP#354 ·
-
good first issue help wanted
難度 2/5 1-3 小時 新手友好度 77/100
維護者通常 1 天內回覆
-
documentation good first issue help wanted
難度 2/5 1-3 小時 新手友好度 76/100
ai-quokka-wannabe/link#40 ·
-
Add `pdfcpu` to the pantry可能已有人在做 關聯的 PR 仍在進行中或已合併。 未關閉
難度 2/5 1-3 小時 新手友好度 72/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
eunomia-bpf/agentsight#240 ·
維護者通常 1 天內回覆