合作机构:阿里云 / 腾讯云 / 亚马逊云 / DreamHost / NameSilo / INWX / GODADDY / 百度统计
JavaScript 运行时中的文件系统 API 已经很久没有这么好了,这是我试图做出一个更好的文件系统 API 的尝试。
我们今天拥有的 JavaScript API 比十年前要好得多。考虑一下从 XMLHttpRequest 到 fetch()的转变:开发者体验显著改善,允许我们编写更简洁、功能性更强的代码来完成同样的事情。异步编程的 promises 的引入允许了这种变化,以及一系列其他变化,使得 JavaScript 更容易编写。然而,有一个领域几乎没有创新:服务器端 JavaScript 运行时的文件系统 API。
Node.js 最初发布于 2009 年,随之诞生了 fs 模块。fs 模块是围绕 Linux 的核心实用程序构建的,其中的许多方法都反映了它们的 Linux 灵感,如 rmdir 、 mkdir 和 stat 。为此,Node.js 成功创建了一个低级文件系统 API,可以处理开发人员希望在命令行上完成的任何事情。不幸的是,这就是创新的终点。
Node.js 文件系统 API 最大的改变是引入了 fs/promises ,将整个实用程序从基于回调的方法移动到基于 promise 的方法。较小的增量变化包括实现 web 流和确保 reader 也实现了异步迭代器。该 API 仍然使用专有的 Buffer 类来读取二进制数据。(尽管 Buffer 现在是 Uint8Array 的子类,但仍然存在不兼容性,这使得使用 Buffers 有问题。)
即使是 Ryan Dhal 在 Node.js 上的继任者 Deno,也没有在文件系统 API 上做太多的改进,它基本上遵循了与 Node.js 中的 fs 模块相同的模式,尽管它使用了 Uint8Arrays,而 Node.js 使用了 Buffer s,并且在不同的地方使用了异步迭代器,但它仍然采用了与 Node.js 相同的低级 API 方法。
只有 Bun,作为服务器端 JavaScript 运行时生态系统的最新成员,甚至尝试使用 Bun.file() 来更新文件系统 API,这是受 fetch() 的启发。虽然我赞赏这种对如何使用文件的重新思考,但当你处理多个文件时,为每个想要处理的文件创建一个新对象可能会很麻烦(当处理数千个文件时,会有一个巨大的性能损失)。除此之外,Bun 希望你使用 Node.js fs 模块进行其他操作。
在花费数年时间在维护 ESLint 的同时与 Node.js fs 模块斗争之后,我问自己,一个现代的文件系统 API 会是什么样子?
带着这些想法,我开始设计 fsx。
fsx库是我围绕现代高级文件系统 API 应该是什么样子的想法的结晶。在这一点上,它专注于支持最常见的文件系统操作,而把较少使用的操作(例如 chmod )抛在后面。(我并不是说这些操作在将来不会被添加,但对我来说,从最常见的情况开始,然后以与初始方法相同的谨慎方式构建更多的功能是很重要的。)
首先,fsx API 在三个运行时包中可用。这些包都包含相同的功能,但绑定到不同的底层 API。这些包是:
所以,开始时,你需要使用最适合你用例的运行时包。为了本文的目的,我将专注于 fsx-node ,但相同的 API 存在于所有运行时包中. 所有运行时包都导出一个 fsx 单例,你可以以类似于 fs的方式使用它。
import { fsx } from "node-fsx";
TOP