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

本文最后更新于:2021年11月3日 下午

场景

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

  • 需要生成 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 千个插件,然而全没用了。是的,这类粘合层工具的寿命实在太短了,而且废弃的太快,所以官方基本上不会去兼容各个构建工具,因为事实上不可能兼容所有的。

1635696863565

解决

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

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

下面是几个这样做的例子

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


是否需要将 cli 工具集成到构建工具中
https://blog.rxliuli.com/p/3e5d207024444d3e9f8395c1302d6201/
作者
rxliuli
发布于
2021年10月31日
许可协议