是否需要将 cl
source link: https://blog.rxliuli.com/p/3e5d207024444d3e9f8395c1302d6201/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
是否需要将 c_
942 字
3 分钟
本文最后更新于：2021年11月1日 凌晨
你是否也曾遇到过下面这样的场景？
- 需要生成 graphql 的类型定义，开启了一个 terminal tab
- 需要生成 i18n json 配置的类型定义，开启了一个 terminal tab
- 需要启动一个依赖的 web 服务，开启了一个 terminal tab
- 需要调试一个依赖的 lib，需要根据变更重新打包，开启了一个 terminal tab
- 需要使用 postcss 监视模式，开启了一个 terminal tab
为什么会出现这些情况？仔细思考一下，有哪些我们本该也需要这样做但并未这样做的事情？
- eslint 代码规范检查
- prettier 格式化
- tsc server
为什么它们不需要？因为它们被集成到 ide 或者构建工具中了，那么，理论上很多工具都可以这样集成，为什么没有人做呢？
让我们从时间上来看一下构建工具的历史
- Grunt
- browserify
- webpack
- anguarl cli/create-react-app/vue-cli
- rollup
- parcel
- esbuild/swc
- vite/snowpack
可以看到，前端构建工具实在太不稳定了，几乎每年换一次（甚至不止一次），每换一次，都是一个生态系统的崩塌。借用阮一峰的话来说：每变一次，前面的那些工具就全没用，都白学。要知道，这些工具每一个都是软件系统，单单 Grunt 就有 4 千个插件，然而全没用了。是的，这类粘合层工具的寿命实在太短了，而且废弃的太快，所以官方基本上不会去兼容各个构建工具，因为事实上不可能兼容所有的。
实际上 vite 为了开发者体验，默认就做了很多粘合，包括支持各类文件 css module、worker、wasm 等等。
那么，这是否意味着这些粘合层的插件不值得做呢？对于官方而言，或许是这样。但对于使用者而言，如果用到的地方太多，那最好还是做一层粘合插件，以此提高开发者体验，尤其是在公司内技术栈统一的情况下，事实上不需要兼容所有的构建工具。
下面是几个这样做的例子
它们都能在某种程度上减少开发者的负担，避免需要开发者了解额外的知识，而仅仅需要使用 npm script 即可，其他的功能都被包含到构建工具的流程中了。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK