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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 1334 天前的主题，其中的信息可能已经有所发展或是发生改变。

目前有若干前端项目，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 的这种大的割裂。大多数时，可以无脑升级大版本号。

webpack

升级

webpack5

Golang

28 条回复 • 2021-04-01 13:00:45 +08:00

Shook

2021-03-31 16:35:45 +08:00

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

LokiSharp

2021-03-31 16:36:00 +08:00

golang 还年轻还没出 2

einsdisp

2021-03-31 16:39:23 +08:00

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

einsdisp

2021-03-31 16:42:50 +08:00

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

einsdisp

2021-03-31 16:48:51 +08:00

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

chenqh

2021-03-31 16:52:56 +08:00

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

einsdisp

2021-03-31 16:58:46 +08:00

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

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

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

duan602728596

2021-03-31 17:11:02 +08:00

现在常用的 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

2021-03-31 17:17:43 +08:00

前端是噩梦。

einsdisp

2021-03-31 17:25:28 +08:00

@duan602728596

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

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

mcfog

2021-03-31 17:36:05 +08:00

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

leelz

2021-03-31 18:27:25 +08:00

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

anonydmer

2021-03-31 18:28:38 +08:00

脚本语言的升级就没有一个让人省心的

LiuJiang

2021-03-31 18:31:07 +08:00

亲，这边建议您使用 Vite 或 Snowpack 代替呢。

lewinlan

2021-03-31 18:38:34 +08:00 via Android

泛型都是 1.1x 了，估计职业生涯内 go 是不会 breaking change 了

fuis

2021-03-31 18:43:18 +08:00

看完全文我也不知道你到底在优化什么

Jirajine

2021-03-31 19:08:03 +08:00 via Android

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