给Electron提的Bug修复啦

大家好,我是老纪。

书接上回《抽丝剥茧:Electron与Node.js的奇葩Bug》,没有看过的读者老爷们推荐阅读一下。

我在ElectronGitHub上提的issue,现在已经关闭了。

我们再简单回顾下这个Bug的背景与产生原因:

  1. Node.js自v18.17.0起,为fs.readdir相关API(同步、异步回调与Promise)都新增了一个参数recursive,但事实上,同步和异步回调的API都有Bug,直到v18.19.0才修复。
  2. Electron v27的多个版本内置的Node.js使用v18.17v18.18,直到v29开始使用Node.js的v20,才没有这个Bug
  3. 由于Electron对fs进行了wrap处理,v29起虽然在大部分情况下没有问题,但是asar模式下内置资源路径的递归没有实现,仍会引发Bug,这也正是此次codebytere修复些问题时的标题:fix: support recursive readdir in Asar files#41582

我们看下codebytere的描述信息:

她其实做了两件事:

  1. 修复asar模式下使用recursive参数的Bug
  2. 规避fs.promises.readdir的性能风险。对于fs.promises.readdir的重写,不再是原来的fs.promises.readdir = util.promisify(fs.readdir),而是依赖于fs.promises.readdir的原生方法本身。原因是我上篇文章提到的,fs.readdir使用recursive参数的异步回调处理是同步的,可能会阻塞进程,有性能上的风险。

从她的代码提交上看,她又手写了两个同步异步的递归函数(代码是从Node.js里借鉴的):

不过我更倾向于把她的762行移到756行,这样可以在readdirRecursive中专注处理asar的逻辑,如果Node.js在这里再有什么Bug,可以随着版本的升级而修复,起码只会影响asar的部分。当然,目前这种修改,对于Electron而言,也无伤大雅,真要有了问题,也就是改多改少的区别了。像这么底层的东西,如果不是这样的API变更,通常是很健壮的。

我这个issue下还有两个开发者反馈遇到了同样的事情:

虽然这个问题关闭了,但新的版本还没有发出来。从目前的提交来看,这个修复只是针对Electron v29+,因为它即使合并到v27v28,由于对应的Node.js版本没有升级到v18.19,其同步和异步回调的API仍是有问题的。

相关推荐
William_Xu1 小时前
React 新旧生命周期对比
前端
PBitW2 小时前
为什么vite中TS报错,可以继续运行?Webpack不行?💡
前端·typescript
GISer_Jing2 小时前
一套H5跑通三端:App+小程序内嵌H5跨端适配全栈解决方案
前端·前端框架·ai编程
码云之上2 小时前
项目团队从 5 人扩到 15 人,我写了个 CLI 让 IDE 共享 AI 规则
前端·人工智能·后端
飞天狗2 小时前
LCP / INP / CLS 三个维度的实战调优:把 Web Vitals 从不及格拉到优秀的完整路径
前端·性能优化
Csvn2 小时前
Vue 3 `<script setup>` 解构 props 后响应式丢了?一个「字段不更新」的排查实录
前端
用户298698530142 小时前
前端 Excel 处理进阶:React 中合并与取消合并单元格的实现
前端·javascript·react.js
Highcharts2 小时前
@highcharts/react完整技术指南|新版Highcharts React使用、迁移、SSR、TS 优化全解
前端·javascript
老王以为2 小时前
Fiber 节点 —— 一个数据结构如何承载整个 React 运行时
前端·react native·react.js