【一库】3款比 `fs` 更强的文件操弄者👺

📖阅读本文，你将

• 明白为啥 fs 根本满足不了日常开发。

• 认识到3个比内置 fs 更强加的文件操作库（以便在写脚本时事半功倍）

• 分别了解到它们的特点；

一、既生 fs，何造轮子？

因为 fs 的 api 不够美丽啊！

公司前端新人小包刚入职三天。

他接到一个任务："写一些 Node.js 脚本，来自动生成一些目录，拷贝和处理一些文件。"

• 最初 ，他需要将 index.css 文件拷贝到 dist/test/css 目录下。

  这看起来是个简单轻易的活儿，熟悉 Node.js 脚本的小包立刻开始了工作，写下了如下代码：

  import { copyFile } from 'fs';
  copyFile(
    'index.css',
    'dist/test/css/index.css', 
    (err) => { ... }
  );
  

  很快啊，小包的代码就报错了，因为 /dist/test/css 这个目录并不存在。

  小包眉头一挑，发现这么多层目录，自己需要写个递归创建目录的方法：

  const makeDirRecursive = () => {
    ... // 省略实现
  }
  

  可是很快，脚本又报错了，这次的原因是：“如果一个目录存在，再次创建它便会报错。”

  为了解决这个问题，小包只好在 makeDirRecursive 方法里加入了 existsSync 方法先判断目录是否存在；

  此时，小包终于完成了自己的第一个小目标。

  但很快，组长又扔来了第二个目标；

• 第二 ，需要删除一个名为 dist/js 的目录，和其中所有的文件。

  查看了一遍 fs 模块的 API 小包懵了：

  “堂堂 Nodejs 居然没有提供直接删除整个文件夹的 api，只提供了单文件删除（unlink） 与 删除文件夹（rmdir）”。

  rmdir() 的 recursive 选项为已弃用 api;

  “好吧……我又要实现递归删除文件夹里所有内容的操作了！”

  这样想着，小包写下如下代码：

  const deleteFolderRecursive = function (directoryPath) {
    // 实现省略
    };
  

• 反思 ，小包写完功能之后，开始反思： “难道所有 Nodejs 开发者都是这样刀耕火种的吗？难道没有更好的工具了吗？”

  不！

  当然不！程序员都是一群偷懒成瘾的家伙，尤其是前端！

  当然有更好的 “文件操弄者”，那些帮助 "Nodejs" 开发早早下班的工具。

二、匠心删除者：rimraf

Node.js 社区的哲学是一个库最好只做好一件小事。

rimraf 就是这样一个剑心澄澈，只做 "删除" 这件小事的库。只做这一件小事，让它拥有了：

• npmjs.com 周下载量 6700 万次。（React 才 1600 万次）
• github star 4.7K; (嗨，做基础工具的，少点 star 就太正常了)

安装：

npm install rimraf --dev
# or
yarn add rimraf -D

用法非常简单：

const rimraf = require('rimraf');

rimraf('dist/js', (err) => {
  if (err) {
    throw err
  }
  console.log('success')
})

优秀的删除 API，就是这样朴实无华且枯燥；

三、手握明月摘星辰： fs-extra

fs-extra 的功能一句话概括："不仅完全支持 fs 模块的所有 api！我还支持那些它没有的。"

如果说 rimraf 只专心做一件小事，那 fs-extra 则振臂一呼，大声喊道：“小孩子才做选择题，成年人表示我都要！”

安装：

npm install fs-extra --dev
# or
yarn add fs-extra -D

前文说到的“小包要判断某个文件夹是否存在，然后递归创建”的动作，在 fs-extra 里简单就像喝水那样自然:

const fs = require('fs-extra')
await fs.ensureDir(directory) // 这就行了

一句话，搞定那个让小包掉了10根头发的递归难题。

除了这，它还提供了哪些能力呢？

• 拷贝 (copy)
• 清空文件夹 (emptyDir)
• 确保文件存在 (ensureFile)
• 确保文件夹存在 (ensureDir)
• 确保连接存在 (ensureLink & ensureSymlink)
• 判断路径是否存在 (pathExists)
• “更便捷”的写文件 (outputFile)
• “更便捷”的读写 JSON (outputJson & readJson & writeJson)
• 删除 （remove）

如果你正准备写一些包含文件操作的 “nodejs脚本” ，那 extra-fs 毫无疑问应该是你首先考虑加入 devDependencies 的工具库之一。

四、我是太阳：fs-jetpack

fs-jetpack 开篇自称：“文件操作API，比 fs 或 fs-extra 方便得多。”

嚯？

你这么说老哥可就不困了，交出你的 API，立刻！马上！

append
copy
createReadStream
createWriteStream
...

才看两秒，眉头一皱，心中冒起了 “平平无奇” 四个汉字。

但是，当我看到以下这段代码时，我立刻改变了自己的看法：

// .
// |- greets
//    |- greet.txt
//    |- greet.json
// |- greets-i18n
//    |- polish.txt

jetpack
  .dir("greets")
  .file("greet.txt", { content: "Hello world!" })
  .file("greet.json", { content: { greet: "Hello world!" } })
  .cwd("..")
  .dir("greets-i18n")
  .file("polish.txt", { content: "Witaj świecie!" });

所有方法——支持链式调用，文件操作届的 jquery 吗？

试想了一些场景，虽然用 Promise 很香，但是如果你是一个 “链式调用” 的狂热爱好者，这一串 dot、dot、dot 的写法足以让你大呼过瘾。

毕竟，对比一下 fs...fs-jetpack 也绝对能算得上真香了。

但是，要说比 fs-extra 更好用？

emmm，我捍卫你说话的权利，仅此而已。毕竟，你比 fs 确实好用多了。

五、结束语

我是春哥。 大龄前端打工仔，依然在努力学习。 我的目标是给大家分享最实用、最有用的知识点，希望大家都可以早早下班，并可以飞速完成工作，淡定摸鱼🐟。

你可以在公众号里找到我：前端要摸鱼。