Make the vendored Node-API sources distinguishable from our own code
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 重构
- 描述清晰度
- 需要澄清
- 活跃度
- 活跃
- 技术栈
- cpp
调研方向
首先盘点 Core/Node-API/Source，并将 js_native_api_v8.cc、js_native_api_v8_internals.h 和 js_native_api_v8.h 与 Node.js 中对应的文件进行比较。审阅 #70、#227、现有的 [BABYLON-NATIVE-ADDITION] 标记，以及 issue 中列出的 upstream 参考。完成的标准是：项目拥有一套达成共识的结构和来源追踪方案，能够区分 upstream 文件、修改过的 upstream 文件和项目内部文件。
由索引模型根据 Issue 内容生成。
描述
[Filed by Copilot on behalf of @bghgary]
Core/Node-API/Source mixes files vendored from Node.js with implementations we wrote, and nothing marks which is which. #227 is what that costs: js_native_api_v8_internals.h looks vendored but is a hand-written shim, and it carried a handle leak from the original 2019 fork until last week.
Syncing does not fix it. #70 ("Update Node-API to latest from node.js") rewrote 54 lines of that same file in 2024 and left the bug in, because the file has no upstream counterpart to copy from — upstream's version pulls in node_internals.h / env.h / util-inl.h, so ours reimplements OneByteString, the CHECK macros and PersistentToLocal locally.
A 3rdparty/<name>/ directory carrying a README or license that links the source would cover the straightforward case, but it doesn't fit cleanly here: we vendor a subset of Node's files and add engine implementations (Chakra, JavaScriptCore, QuickJS) alongside them.
What structure actually works is the open question:
- which files are verbatim upstream, which are modified upstream, and which are ours
- where the upstream ref is recorded, so a future sync knows what it is syncing from
- whether per-change markers are enough — the
[BABYLON-NATIVE-ADDITION]convention is currently 7 lines injs_native_api_v8.cc, 3 injs_native_api_v8_internals.h, and 0 injs_native_api_v8.h
- 主要语言
- C++
- 星标
- 22
- 派生
- 23
- 平均合并
- 4 天 8 小时
- 30 天内合并 PR
- 3
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
BabylonJS/JsRuntimeHost 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 84/100
BabylonJS/JsRuntimeHost#234 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
BabylonJS/JsRuntimeHost#173 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 42/100
BabylonJS/JsRuntimeHost#241 · 3 条评论 ·
维护者通常 1 天内回复
-
napi_unwrap does not reject objects that were never wrapped (V8 port faults, QuickJS port confuses types)可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 4/5 3-5 天 新手友好度 68/100
BabylonJS/JsRuntimeHost#226 ·
维护者通常 1 天内回复
-
bug
难度 4/5 3-5 天 新手友好度 35/100
BabylonJS/JsRuntimeHost#219 ·
维护者通常 1 天内回复
查看 BabylonJS/JsRuntimeHost 的全部 Issue
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 78/100
gavinlouuu-kpt/mib-studio-qt#517 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 73/100
EchoTools/nevr-runtime#116 ·
维护者通常 1 天内回复
-
code-quality libc++
难度 1/5 1 小时以内 新手友好度 82/100
llvm/llvm-project#229284 ·
维护者通常 1 天内回复
-
test-issue
难度 2/5 1-3 小时 新手友好度 82/100
llvm/offload-test-suite#1557 ·
维护者通常 1 天内回复