chainWebpack与configureWebpack

如果没理解错的话,如果对一个loader或plugin修改的配置如果是一项的话推荐
chainWebpack、如果是多项的话用configureWebpack直接覆写

看个人习惯,反正我就喜欢用 chainWebpack

大概是版本不同,网上光关于loader或plugin使用vue-cli的配置就有好多种。难道不能更趋近webpack的原生配置吗?一个版本一套,本来webpack4搭建不难的,用这个脚手架真是鸡肋

先说第一个问题,chainWebpack 和 configureWebpack 的区别。

chainWebpack 的底层是 webpack-chain,命令式 Webpack 配置的事实标准,提供了一套灵活的上层 API 进行 Webpack 配置而无需过分关注 Webpack Config 的规范细节。configureWebpack 的底层是 webpack-merge,能让你通过编写一个配置子集快速合并到最终的完整配置中。

那么问题来了,如果我只是想修改已经存在于基础配置中的某个 loader 的选项,我用 configureWebpack 要怎么做?直接编写与那个 loader 相关的配置子集的话,很可能会覆盖掉有用的预置选项。

第二个问题,Vue CLI 配置到底有几套。

在 Vue CLI 3 之前,Webpack 配置的部分是靠工程模板暴露给用户的,模板里是啥样 Webpack 配置就是啥样,Vue CLI 只是提供了一些预置配置和命令。你说的「一个版本一套」,其实是模板而不是 CLI。考虑到模板是 UGC,版本混乱的锅真不该 Vue CLI 来背。Vue CLI 3 开始 Webpack 配置就被封装到 vue.config.js 中了。为什么不再暴露原生 Webpack 配置文件,看后文。

第三个问题,Vue CLI 3 为什么要这么做(而不是暴露出 Webpack 配置本身)。

如果经历过较长时间的 Vue CLI 2 项目,你大概能遇到「模板升级」的问题。一个工程通过模板初始化好后,工程配置部分就基本固定了。当这个模板升级带来了更优秀的工程配置,你就要面对如何引入新配置的难题。重新初始化项目,太肉疼;对比新旧模板差异并手动引入,太心累。总之就是很恼人。Vue CLI 3 放弃模板转向插件,就是希望能通过动态生成的方式解决这个问题。插件升级,你无需再关心哪里有变化、要如何引入到现有工程,你需要做的只是升级插件依赖的版本(预期 Vue CLI 4 甚至可以帮你升级你的业务代码)。但实现这一效果的前提就是 Webpack 配置由 Vue CLI(及各种插件)来管理操控。举一个简单的例子:原本 webpack.config.js 在 /build 下的,你出于某种原因移到了工程根目录,Vue CLI 要如何跟踪并更新配置呢?

一切的抉择都是取舍。Vue CLI 3 的改变是为了能减少开发者在非业务代码方面的消耗,提供更好的工程演进体验。

1 Like

尤其第三点是亮点。看来还要慢慢习惯webpack-chain的这种配置。