Version-derived feature flags in the node implementor misfire on runtimes that report a fictional Node version
還沒有人認領這個 Issue。
評估
- 難度
- 5/5
- 預估耗時
- 一週以上
- 新手友好度
- 35/100
- Issue 類型
- 缺陷
- 描述清晰度
- 需要釐清
- 活躍度
- 冷清
- 技術堆疊
- bun, deno, javascript, node.js
- 領域
- testing-qa
研究方向
從 implementors/node/features.js 和 node implementor README 開始；檢查現有的 process.version 檢查以及 #68 中的先例。決定 node implementor 應該記錄其對真實 Node 的假設，還是在啟用 flags 前偵測能力。完成的標準是，所選擇的行為能夠防止外部執行環境嘗試不受支援的 SharedArrayBuffer 情況。
由索引模型根據 Issue 內容生成。
描述
implementors/node/features.js derives experimentalFeatures.sharedArrayBuffer and
runtimeFeatures.dataviewSharedArrayBuffer from process.version. While exploring how
far foreign runtimes get with the suite, I ran it through the node implementor under
Deno 2.9.5, and its Node compatibility mode reports process.version as v26.3.0, a
Node version that does not exist. The version comparison therefore enables the
SharedArrayBuffer cases, but Deno exports neither node_api_create_sharedarraybuffer
nor node_api_is_sharedarraybuffer, so the addon fails at load time instead of the test
being skipped: on Linux the process exits 127 on the unresolved symbols, and on Windows
dlopen reports it cannot load the addon. The suite output then reads like a broken
test rather than a missing feature. Bun does the same kind of impersonation, its stable
1.3.14 reports v24.3.0 and its current canary also reports v26.3.0, so any invented
version string can end up in these comparisons.
For Node itself the version checks are exactly right, and #26 already made features.js
a per-implementor file, so an eventual bun or deno implementor would declare its own
honest flags. The situation above only exists in the period before such implementors do,
which is also exactly when someone evaluates a new runtime by pointing the node
implementor at it. So a small question rather than a proposal: is that simply out of
scope for the node implementor (worth a sentence in its README that its flags are only
meaningful under real Node), or would you want flags like these derived from a probe of
the actual runtime rather than from the version string? #68 adds one more flag in the
current version-derived style, so whatever you prefer would apply there too. Happy to
help with either outcome.
- 主要語言
- 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 則留言 ·
-
難度 4/5 3-5 天 新手友好度 48/100
nodejs/node-api-cts#84 ·
-
Port SharedArrayBuffer TypedArray test可能已有人在做 @hexbinoct 於 70 天前認領。 未關閉
難度 3/5 1-2 天 新手友好度 45/100
nodejs/node-api-cts#61 ·
-
難度 4/5 3-5 天 新手友好度 35/100
nodejs/node-api-cts#35 · 1 個 reaction ·
-
難度 4/5 3-5 天 新手友好度 45/100
nodejs/node-api-cts#34 ·
查看 nodejs/node-api-cts 的全部 Issue
相似的 Issue
-
initramfs: -type f (#18686) skips the libcurl.so.4 symlink, libcurl no longer copied into initramfs未關閉
難度 2/5 1-3 小時 新手友好度 72/100
維護者通常 2 天內回覆
-
難度 2/5 1-3 小時 新手友好度 72/100
UNIVERSE-HPC/course-material#283 ·
-
bug C/C++ code
難度 1/5 1 小時以內 新手友好度 78/100
webarkit/WebARKitLib#85 ·
維護者通常 1 天內回覆
-
難度 1/5 1 小時以內 新手友好度 75/100
-
難度 2/5 1-3 小時 新手友好度 62/100
維護者通常 1 天內回覆