升级 webpack 5 遇到的坑，果然过早的优化是万恶之源

資深大佬 : einsdisp 3

目前有若干前端项目，2 年前的时候抽象出了一个用于构建的工具包 boilerplate （类似 create-react-app 这种），当时用的 webpack 4，大概各种构建工具使用的版本现在比较老了，每次安装 /升级包的时候，npm 就提示有两百多个漏洞

found 2xx low severity vulnerabilities

这么多漏洞，可能其实并没有啥危害，但对于强迫症而言，就是看着不爽。关键很多漏洞要解决的话，根据 npm audit 提示，很多包必须升级大版本号，特别是要升级到 webpack v5 。

近期正好要修改 boilerplate 包，添加一些功能，于是一派脑门，打算干脆一不做二不修，升级到 webpack v5，结果折腾两天，发现有很多的插件 /工具尚不支持 webpack 5，或者有 bug，或者是声明的 dependencies/peerDependencies 仍然绑定着 v4 版本的 webpack 或者 @types/webpack 。

然后才想起来，看了下 create-react-app 的 issue，发现这种级别的项目也还没完全支持 webpack 5 呢： https://github.com/facebook/create-react-app/issues/9994 （看这个 issue，还有一些工作没完成呢）

看来 webpack5 的生态还不完善，不想当小白鼠，花费太多时间在工具链的配置 /升级上毫无意义，而且 webpack v5 的新特性也没啥刚需，目前 v4 下，构建时间也还可以。于是果断放弃，继续用回 webpack 4，两天时间白费力，郁闷。果然过早的优化是万恶之源，v5 去年 10 月发布正式版，现在升级到 v5 还是太早了，估计至少等一年生态系统才会比较完善。

这个时候就显示出 golang 的好处了，golang 的生态环境，很少出现 python2 vs python3，webpack4 vs webpack5 的这种大的割裂。大多数时，可以无脑升级大版本号。

大佬有話說 (28)

資深大佬 : Shook

然后等版本稳定了，webpack6 就要出来了。
这和买游戏机的逻辑差不多。
資深大佬 : LokiSharp

golang 还年轻还没出 2
主資深大佬 : einsdisp

@Shook 对的，其实这样挺好，软件包总是使用次大版本号，保证足够稳定（如果最新大版本号没有刚需功能的话）。像很多服务器发行版，里面的软件就挺老的。
主資深大佬 : einsdisp

@Shook 游戏机跟生产力软件不是一回事。购买最新的游戏机，哪怕有些游戏无法运行 /没有适配也无所谓，等等就行，晚玩几天死不了。生产力软件乱升大版本号，导致其依赖的其他软件 /插件失效或者不稳定，是要命的。这就是使用次大版本号的好处
主資深大佬 : einsdisp

@LokiSharp golang 2 只是个代号（类似 alpha/next 这种含义），很可能永远不会出 v2
資深大佬 : chenqh

那是因为 golang 基本没有语法变动，但是不代表 golang 的第三方库可以无脑升大版本呀
主資深大佬 : einsdisp

@chenqh 嗯。第三方库升级大版本的话，就算不是无脑升级，一般 API 改动也不会太大，需要调整的代码也很少。很少出现 webpack v4 v5 这种牵一发而动全身的事情。

golang 语言本身就是奉行极简主义，如无必要误增实体。影响这第三方库也大体如此。我对比过很多相同定位的 python 库与 golang 库，golang 的库功能简略的多。

大概 golang 的第三库本身就很极简，所以升级大版本号非常平滑。
資深大佬 : duan602728596

现在常用的 loader 和 plugin 已经支持 webpack5 了。给我自己项目用的搞的脚手架和我们项目用的 umi，升级到 webpack5 后都没有问题。有问题的有可能是 loader 和 plugin 本身 api 的变化。

声明 webpack4 的，有些是已经废弃的，可能是 webpack 已经内置的功能，有些是不需要升级的，没有用到 webpack 已经废弃的 api，所以兼容 webpack5 。在 ts 编译时忽略错误即可。

webpack5 的 top-level-await 、Module Federation 、filesystem cache 等都很有用，并且编译速度真的是大幅度提升，我们的项目编译时间从 4 分钟缩短到 2 分钟内，在 docker 内的打包时间从 10 分钟降低到 3 分钟。
資深大佬 : wangkun025

前端是噩梦。
主資深大佬 : einsdisp

@duan602728596

嗯嗯，常见的 loader 与插件很多已经支持 v5 。不幸我的这脚手架用了一个比较小众的插件“error-overlay-webpack-plugin”，是从 create-reate-app 中提取出来的，开发的时候可以直接在页面看到前端代码的错误提示，感觉挺方便的（不同于 webpack 的 overlay，那个只能显示 webpack 自身的编译错误）

昨天还去这个插件的 issues 里看了下，尚不支持 v5，因为上游的 create-reate-app 也还没完全迁移到 v5
資深大佬 : mcfog

你好，golang 并不无脑
支持 gomod 的不支持 gomod 的，protobuf 新老两个版本的，grpc 几次不兼容升级的
etcd 和 grpc 不是左边不对就是右边不对，至今用着毛子的 fork
資深大佬 : leelz

最近也在干升级 webpack5，还算平滑。踩到的坑基本都能搜得到解决办法。升级 mini-css-extract-plugin 这个就能干掉很多 warning 了
資深大佬 : anonydmer

脚本语言的升级就没有一个让人省心的
資深大佬 : LiuJiang

亲，这边建议您使用 Vite 或 Snowpack 代替呢。
資深大佬 : lewinlan

泛型都是 1.1x 了，估计职业生涯内 go 是不会 breaking change 了
資深大佬 : fuis

看完全文我也不知道你到底在优化什么
資深大佬 : Jirajine

你说 golang 简单，实际上你的项目如果深度定制了 webpack，那是你的项目本身复杂。
很多 webpack 特有的、深度定制的各种功能、插件其实是不必要的，如果你奉行所谓 golang 那种保持简单理念组织项目结构，那么完全可以不用 webpack，直接用 parcel/rollup/snowpack 这些无痛的、简单的方案就可以了。
資深大佬 : shawn102400

golang 体现好处个鬼，golang 的坑比其他语言都多，实在是人力不够填不完罢了。golang2.0 都计划 5 年了，还没搞出来，就泛型和异常处理这两个坑，至少填几年。
資深大佬 : gzwgq222

最近也在升级 webpack5，也碰到了一些问题。比如会去编译组件说明的 markdown 文件，提示 md 语法错误，还没抽时间去查原因。虽然 V4 的构建速度已经优化一波了，大约提升了 70%~80%，但还是想试试 V5 。
資深大佬 : bojackhorseman

借问一下，怎么熟练掌握 webpack 啊。平常做项目都是脚手架一把梭。离了脚手架就成了智障，但对于前端而言，还是想多了解一下的，看官方文档，内容很多概念也很繁复，老实说，并不能很有效的理解。
資深大佬 : Sparetire

大版本升级本来就是会有 breaking change 的，你对大版本升级的期望是无脑升，我一时竟不知道是谁有问题。。
标题说过早优化，通常我们说过早优化是形容优化代码，整篇洋洋洒洒看下来也没看见和优化代码有什么关系
資深大佬 : WillBC

webpack 的学习和使用体验就是
資深大佬 : byte10

@WillBC 头大，golang 和 node 其实很像的，就是轮子多，小猫小狗都可以搞轮子。
資深大佬 : sjhhjx0122

自从用了 vite 就回不去了
資深大佬 : fulvaz

不要方, 等到 lts 的最后一天升级也不迟
資深大佬 : yaphets666

干了快 3 年前端了.越来越觉得前端是一团迷雾,多得是不知道的坑.有些想转 java 了
資深大佬 : ezreal

vite 方便多了
資深大佬 : dany813

利好 vite