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 会是什么样子？
{ encoding: "utf8" } )。fs 模块最大的抱怨就是它抛出错误的频率。在不存在的文件上调用 fs.stat() 会抛出错误，这意味着你实际上需要将每个调用包装在 try-catch 中。为什么？对于大多数应用程序来说，缺少文件并不是不可恢复的错误。带着这些想法，我开始设计 fsx。
fsx 库是我围绕现代高级文件系统 API 应该是什么样子的想法的结晶。 在这一点上，它专注于支持最常见的文件系统操作，而把较少使用的操作(例如 chmod )抛在后面。 (我并不是说这些操作在将来不会被添加，但对我来说，从最常见的情况开始，然后以与初始方法相同的谨慎方式构建更多的功能是很重要的。)
首先，fsx API 在三个运行时包中可用。这些包都包含相同的功能，但绑定到不同的底层 API。这些包是：
fsx-node - Node.js 中 fsx API 的绑定fsx-deno - fsx API 的 Deno 绑定fsx-memory - 适用于任何运行时(包括 web 浏览器)的内存实现所以，开始时，你需要使用最适合你用例的运行时包。 为了本文的目的，我将专注于 fsx-node ，但相同的 API 存在于所有运行时包中. 所有运行时包都导出一个 fsx 单例，你可以以类似于 fs 的方式使用它。
import { fsx } from "fsx-node";
文件是通过使用返回特定数据类型的方法来读取的：
fsx.text(filePath) 读取给定的文件并返回一个字符串。fsx.json(filePath) 读取给定的文件并返回一个 JSON 值。fsx.arrayBuffer(filePath) 读取给定的文件并返回一个 ArrayBuffer 。这里有一些例子：
// read plain text
const text = await fsx.text("/path/to/file.txt");
// read JSON
const json = await fsx.json("/path/to/file.json");
// read bytes
const bytes = await fsx.arrayBuffer("/path/to/file.png");
如果文件不存在，每个方法都会返回 undefined 而不是抛出错误。这意味着您可以使用 if 语句而不是 try-catch，并且可以选择使用 nullish 合并运算符来指定默认值，如下所示：
// read plain text
const text = (await fsx.text("/path/to/file.txt")) ?? "default value";
// read JSON
const json = (await fsx.json("/path/to/file.json")) ?? {};
// read bytes
const bytes =
(await fsx.arrayBuffer("/path/to/file.png")) ?? new ArrayBuffer(16);
我觉得这种方法在 2024 年比不断担心不存在的文件出错更有 JavaScript 风格。
要写文件，调用 fsx.write() 方法。这个方法接受两个参数：
filePath:string - 写入的路径value:string|ArrayBuffer - 写入文件的值这里有一个例子：
// write a string
await fsx.write("/path/to/file.txt", "Hello world!");
const bytes = new TextEncoder().encode("Hello world!").buffer;
// write a buffer
await fsx.write("/path/to/file.txt", buffer);
作为额外的好处，fsx.write() 将自动创建任何尚不存在的目录。这是我经常遇到的另一个问题，我认为它应该在现代文件系统 API 中“正常工作”。
要确定一个文件是否存在，使用 fsx.isFile(filePath) 方法，如果给定的文件存在，则返回 true ，否则返回 false 。
if (await fsx.isFile("/path/to/file.txt")) {
// handle the file
}
与 fs.stat() 不同，如果文件不存在，这个方法会返回 false ，而不是抛出错误。
try {
const stat = await fs.stat(filePath);
return stat.isFile();
} catch (ex) {
if (ex.code === "ENOENT") {
return false;
}
throw ex;
}
fsx.delete() 方法接受一个参数，即要删除的路径，并且对文件和目录都有效。
// delete a file
await fsx.delete("/path/to/file.txt");
// delete a directory
await fsx.delete("/path/to");
fsx.delete() 方法故意过于激进：它会递归地删除目录，即使它们不是空的(实际上是 rmdir -r )。
fsx 的一个关键特性是，由于其内置的日志系统，很容易确定哪些方法被调用，并使用了哪些参数。要启用 fsx 实例的日志记录，请调用 logStart() 方法并传入一个日志名称。当你完成日志记录时，请调用 logEnd() 并传入相同的名称来检索日志条目的数组。
fsx.logStart("test1");
const fileFound = await fsx.isFile("/path/to/file.txt");
const logs = fsx.logEnd("test1");
每个日志条目都是一个包含以下属性的对象：
timestamp - 创建日志的数字时间戳type - 描述日志类型的字符串data - 与日志相关的附加数据对于方法调用，日志条目的 type 是 call ，而 data 属性是一个对象，包含：
methodName - 被调用的方法的名称args - 传递给方法的参数数组。对于前面的例子， logs 将包含一个条目：
// example log entry
{
timestamp: 123456789,
type: "call",
data: {
methodName: "isFile",
args: ["/path/to/file.txt"]
}
}
了解这一点后，您可以轻松地在测试中设置日志记录，然后检查调用了哪些方法，而无需使用第三方间谍库。
fsx 的设计是这样的，抽象的核心功能包含在 fsx-core 包中，每个运行时包都扩展了该功能，使用特定于运行时的文件系统操作实现，这些操作被包装在一个称为 impl 的对象中。
fsx 单例fsx 的另一个实例(比如 fsx-node 中的 NodeFsx )impl 实例(如 node-fsx 中的 NodeFsxImpl )。这可以让您只使用所需的功能。
每个 fsx 实例都有一个 base 类实现，它定义了 fsx 对象在生产环境中的行为。active impls 是在任何给定时间使用的实现，它可能也是 base 类实现，也可能不是。你可以调用 fsx.setImpl() 来改变 active impls。
import { fsx } from "fsx-node";
fsx.setImpl({
json() {
throw Error("This operation is not supported");
},
});
// somewhere else
await fsx.json("/path/to/file.json"); // throws error
在此示例中，基本实现被替换为自定义实现，该自定义实现在调用 fsx.json() 方法时会引发错误。这使得您可以轻松地模拟测试方法，而不必担心它可能如何影响整个包含的 fsx 对象。
假设你有一个名为 readConfigFile() 的函数，它使用了来自 node-fsx 的 fsx 单例来读取名为 config.json 的文件，当测试这个函数时，你不想让它实际访问文件系统，你可以把 fsx 的实现换成 fsx-memory 提供的内存文件系统实现，如下：
import { fsx } from "fsx-node";
import { MemoryFsxImpl } from "fsx-memory";
import { readConfigFile } from "../src/example.js";
import assert from "node:assert";
describe("readConfigFile()", () => {
beforeEach(() => {
fsx.setImpl(new MemoryFsxImpl());
});
afterEach(() => {
fsx.resetImpl();
});
it("should read config file", async () => {
await fsx.write("config.json", JSON.stringify({ found: true });
const result = await readConfigFile();
assert.isTrue(result.found);
});
});
这就是使用 fsx 在内存中模拟整个文件系统是多么容易。您不必像模块加载器拦截那样担心导入所有测试模块的顺序，也不需要经历包含模拟库的过程以确保一切正常。您只需更换测试的 impl，然后再重置它。通过这种方式，您可以以更高性能且不易出错的方式测试文件系统操作。
不幸的是，在我发布 fsx 的时候，亚马逊发布了一款名为 FSx 的产品。如果它获得任何支持，我可能会重命名这个库，欢迎提出建议。
长期以来，我们一直在使用 JavaScript 运行时中笨拙的低级文件系统 API。fsx 库是我尝试重新想象现代文件系统 API 的样子，如果我们花一些时间关注最常见的情况，并改进 JavaScript 语言目前提供的人体工学设计。通过从头开始重新思考，我认为 fsx 为我们提供了一种更愉快的文件系统体验。
基础库只关注我最常用的方法，但我计划在了解和思考用例后添加更多方法。您今天就可以试用，欢迎反馈。我很想知道你的想法！