是否需要将 cli 工具集成到构建工具中

场景

你是否也曾遇到过下面这样的场景？

• 需要生成 graphql 的类型定义，开启了一个 terminal tab
• 需要生成 i18n json 配置的类型定义，开启了一个 terminal tab
• 需要启动一个依赖的 web 服务，开启了一个 terminal tab
• 需要调试一个依赖的 lib，需要根据变更重新打包，开启了一个 terminal tab
• 需要使用 postcss 监视模式，开启了一个 terminal tab
• 。。。

为什么会出现这些情况？仔细思考一下，有哪些我们本该也需要这样做但并未这样做的事情？

• eslint 代码规范检查
• prettier 格式化
• tsc server

为什么它们不需要？因为它们被集成到 ide 或者构建工具中了，那么，理论上很多工具都可以这样集成，为什么没有人做呢？

历史

让我们从时间上来看一下构建工具的历史

• Grunt
• browserify
• Gulp
• webpack
• anguarl cli/create-react-app/vue-cli
• rollup
• parcel
• esbuild/swc
• vite/snowpack
• …

可以看到，前端构建工具实在太不稳定了，几乎每年换一次（甚至不止一次），每换一次，都是一个生态系统的崩塌。借用阮一峰的话来说：每变一次，前面的那些工具就全没用，都白学。要知道，这些工具每一个都是软件系统，单单 Grunt 就有 4 千个插件，然而全没用了。是的，这类粘合层工具的寿命实在太短了，而且废弃的太快，所以官方基本上不会去兼容各个构建工具，因为事实上不可能兼容所有的。

解决

实际上 vite 为了开发者体验，默认就做了很多粘合，包括支持各类文件 css module、worker、wasm 等等。

那么，这是否意味着这些粘合层的插件不值得做呢？对于官方而言，或许是这样。但对于使用者而言，如果用到的地方太多，那最好还是做一层粘合插件，以此提高开发者体验，尤其是在公司内技术栈统一的情况下，事实上不需要兼容所有的构建工具。

下面是几个这样做的例子

• vite-plugin-checker（灵感来源）
• rollup-plugin-i18next-dts-gen
• vite-plugin-tauri

它们都能在某种程度上减少开发者的负担，避免需要开发者了解额外的知识，而仅仅需要使用 npm script 即可，其他的功能都被包含到构建工具的流程中了。