在 #26560 中提到,这是一个单独的问题需要跟踪。
预检清单
- 我已阅读了此项目的 Contributing Guidelines。
- 我同意遵循此项目遵循的 Code of Conduct。
- 我在问题跟踪器中搜索了一个与我想提交的功能请求相匹配的问题,但没有成功。
问题描述
#26560 是关于 timeout
模块在主进程中不起作用的问题。看起来像是一些 Node.js 测试 are disabled。所以我必须假设 Electron 和 Node.js 之间有一些已知的差异。几个月前我遇到的另一件事是 Electron 使用 BoringSSL 而不是 OpenSSL。
建议的解决方案
当我搜索 "electron node.js differences" 时,我只找到了这个页面 https://www.electronjs.org/docs/development/electron-vs-nwjs。我建议创建一个类似的标题为 "Differences between Node.js and Electron's Node.js fork" 的页面。这个页面将:
- 建立 Electron 甚至使用了分叉而不是原始的 Node.js(这对每个人来说可能并不明显)
- 列出与分叉链接到 GitHub issue 的已知问题(例如 vm module timeout option not working in main process #26560)
- 已知的故意存在的差异,并附带简短的解释,例如 BoringSSL 的使用。
其他信息
从我脑海中浮现出的至少有以下三个:
- vm timeout (vm module timeout option not working in main process #26560)
- BoringSSL (Electron's use of BoringSSL #20204)
- 与 Node.js 不同的ctrl+c处理方式 (Quit gracefully when Ctrl-C is pressed in console #5273)
我会继续添加更多,因为它们会出现:
6条答案
按热度按时间lymnna711#
我喜欢这个想法。
x6492ojm2#
这有点道理,但只是为了澄清一两点。
确认Electron甚至使用了分叉而不是普通的Node.js(这对每个人来说并不明显)
Electron不再有node的分叉,如果你查看我们的DEPS文件,你会看到我们直接依赖于GitHub上的
nodejs/node
仓库中的一个标签。列出与GitHub问题链接的已知问题(例如#26560)
这很棘手,因为我喜欢避免包含已知错误列表的页面。这就是问题跟踪器的作用,为它创建一个版本控制的文档只会增加重复。可能更好的做法是使用
nodejs-divergence
或其他类似的东西来标记某些问题,以表示它会导致与NodeJS不同的行为。尽管有些事情我们可以/应该记录,但它们不是bug,而是有意的差异。例如,我们使用BoringSSL的事实,或者我们在渲染过程中禁用了NodeJS的ESM加载器。我们很快就会在渲染过程中禁用
vm
模块(这是你的第3点)。TLDR:记录使我们与node分道扬镳的设计决策👍 记录我们所有的bug👎
bvhaajcl3#
Electron 不再有 node 的分支,如果你查看我们的 DEPS 文件,你会看到我们直接依赖于 GitHub 上的
nodejs/node
仓库中的一个标签。我对 Electron 的内部不太熟悉。这个文件夹是用来做什么的?https://github.com/electron/electron/tree/46972abf8b949af80ea18b81df92ceeaa26ce00d/patches/node 也许术语“fork”不是很准确,但在 git 术语中,应用补丁和实际维护一个 fork 之间有什么实际区别?Electron 修补 Node.js,这可能导致错误,也可能导致已知的故意差异。或者不是吗?
这个问题很棘手,因为我喜欢避免包含已知 bug 列表的页面。这就是问题跟踪器的作用,为它创建一个版本控制的文档只会增加重复。
我完全同意。我更关心那些不会修复的 bug,因为它们是设计决策(就像你建议的那样)。然后文档可以链接到搜索该标签,例如
nodejs-divergence
。而不是 bug 但却是有意为之的差异
这就像是上面的 fork 术语加上了“bug”这个词。
让我退后一步,非常清楚地说明我的最初意图是什么:一个刚接触 Electron 的人阅读类似以下内容:
Electron 使用 Chromium 和 Node.js,因此您可以使用 HTML、CSS 和 JavaScript 构建您的应用程序。
https://www.electronjs.org/
或者
Electron 在主进程和渲染进程中都暴露了对 Node.js API 及其模块的完整访问权限。
https://www.electronjs.org/docs/tutorial/quick-start#nodejs-api
现在这个人刚开始接触 Electron 并开始着手进行项目开发。最终,他们遇到了一些他们认为是 bug 的行为。他们运行
node index.js
与electron index.js
以及一个简化的代码来追踪问题(不使用 Electron API)。他们绝对困惑为什么相同的代码在相同的process.versions.node
下会做不同的事情。甚至都不曾想过这是可能的。他们没有预料到 Electron 是如何将 Node.js 和 Chromium 结合在一起的。作为维护者,你们对这些事情一无所知,这是在如此深入的项目中完全自然的过程。对于我这样的新人来说,我不知道发生了什么。所以我要求的只是明确表明这些差异是可以发生的,为什么会发生以及其中一些东西无法修复(当您期望相同的 Node.js 版本在同一台机器上执行相同操作时,这些确实是 bug )。
这有道理吗?
dpiehjr44#
我已经感到困惑了,但你是否能进一步解释一下Node.js事件循环是如何与Chrome和V8事件循环交织在一起的?
从测试来看,尽管明确调用了V8 API来刷新事件队列,但Promise任务(来自V8)似乎并没有在Node.js事件循环中运行。
你到底做了什么让Node.js不知道它没有控制V8?
2fjabf4q5#
@NotWearingPants this talk deck 可能会有所帮助。
mu0hgdu06#