?阅读本文，你将
明白为啥 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# oryarn 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，立刻！马上！
appendcopycreateReadStreamcreateWriteStream...
才看两秒，眉头一皱，心中冒起了 “平平无奇” 四个汉字。
但是，当我看到以下这段代码时，我立刻改变了自己的看法：
// .// |- greets// |- greet.txt// |- greet.json// |- greets-i18n// |- polish.txtjetpack .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 确实好用多了。
五、结束语
我是春哥。 大龄前端打工仔，依然在努力学习。 我的目标是给大家分享最实用、最有用的知识点，希望大家都可以早早下班，并可以飞速完成工作，淡定摸鱼?。
你可以在公众号里找到我：前端要摸鱼。