webpack@v4升级踩坑(小结)

今天我要和大家分享关于 webpack@v4 升级过程中的一些挑战与经验。之前我曾尝试过升级，但因为部分插件的不兼容问题未能成功。今天，我决定再次尝试，看看在我的项目中会遇到哪些挑战。希望这篇文章能为正在考虑升级 webpack 版本的小伙伴们提供一些参考。

一、查阅更新日志

在安装更新之前，我首先仔细研究了 webpack 的更新日志。我了解到，对于大部分用户来说，迁移时需要注意以下几点：

1. 在命令行界面运行打包指令需要安装 webpack-cli。

2. 打包时需要指定打包模式，如 production 或 development。不同模式下会添加不同的默认配置。其中，webpack.DefinePlugin 插件的 process.env.NODE_ENV 的值将自动根据模式添加，无需再手动定义。

3. 不再需要在 plugin 中设置 new webpack.optimize.UglifyJsPlugin。只需在配置中设置开关即可。在 production 模式下，该插件将自动开启。可以通过 optimization.minimizer 指定其他压缩库。

4. CommonsChunkPlugin 已被移除，其功能已迁移至 optimization.splitChunks 和 optimization.runtimeChunk。

二、迁移过程

我首先安装了的 webpack、webpack-cli 和 webpack-dev-server。接着，为开发和发布分别配置了 mode，并删除了 webpack.DefinePlugin 配置。我去掉了 package.json 中启动脚本的 NODE_ENV 环境变量定义。我移除了 new webpack.optimize.UglifyJsPlugin 和 ModuleConcatenationPlugin 的配置。

三、遇到的挑战与解决方案

在配置完成后，我遇到了第一个问题：打包时 extract-text-webpack-plugin 插件出现问题。我尝试了两种解决方案：

1. 安装指定版本的 extract-text-webpack-plugin，即 @next 版本。

2. 使用 mini-css-extract-plugin 替代 extract-text-webpack-plugin。

在使用方法二时，打包发布时需要注意配置css压缩库和js压缩库。一旦在optimization.minimizer中指定了配置，就会弃用内置的代码压缩。以下是具体的操作步骤和配置示例。

在webpack的配置文件webpack.config.js中，我们引入了MiniCssExtractPlugin，这是一款用于提取CSS的代码插件。对于不同的模块规则，我们分别处理了.css和.less文件的处理方式，包括使用MiniCssExtractPlugin.loader、css-loader、postcss-loader以及less-loader等。根据开发环境的不同，对规则进行了相应的调整。

而在生产环境的配置文件webpack.config.prod.js中，我们使用了webpack-merge来合并基础配置，同时加入了针对生产环境的配置。包括设置mode为production、优化选项和插件的配置。在优化选项中，我们使用了UglifyJsPlugin来压缩JS代码，以及OptimizeCSSAssetsPlugin来压缩CSS资产。对于CSS的提取，我们使用了MiniCssExtractPlugin，将CSS提取到单独的文件中。

在使用过程中，可能会遇到一些问题，比如happypack的使用问题。遇到问题时不要惊慌，只需要进行升级操作即可。推荐使用happypack与extract-text-webpack-plugin搭配使用，以达到更好的效果。至于mini-css-extract-plugin，尚未进行测试。在使用过程中需要注意一些问题，但总体来说，这些工具都能帮助我们更高效地管理和优化前端资源。

通过合理的配置和使用，我们可以充分利用这些插件和工具的优势，提高前端开发的效率和性能。在使用过程中遇到任何问题，都可以尝试查找相关资料或者向社区寻求帮助。Webpack Browser Plugin遭遇问题，不必惊慌，暂时弃用，转而配置devServer中的open和openPage功能，轻松应对小场面。

在配置过程中，我遇到了一个有趣的问题。在开发配置中，我尝试使用判断语句process.env.NODE_ENV === 'development'来引入css-hot-loader。实际操作中却发现这个值竟然是undefined。咦？这是怎么一回事呢？经过查阅更新日志，我了解到process.env.NODE_ENV这个变量仅在打包的代码中设置，而在配置文件中是无法获取的。我对此进行了实际验证，结果确实如此。我在package.json的开发启动脚本中仍然加上了NODE_ENV='development'，确保开发环境的正确性。

总体上看，现在的升级环境已经相当成熟，大部分需要用到的功能和插件都有平滑的升级或替代方案。建议在开始升级前安装发布的插件版本，可以参考我的项目配置进行。一些插件的API也进行了更新，如果你是插件开发者，可以尝试发布新的插件版本。我在尝试提取插件时发现自己的版本号中piler.plugin已经过时了。在webpack@v4中，应使用的piler.hooks.emit.tap触发事件。这部分提醒虽然有些突兀，但确实是为了更好地适应新的开发环境。

关于Cambrian的渲染部分，可以通过调用cambrian.render('body')来呈现页面内容，使得网页更加生动和丰富。总体而言，只要我们紧跟时代步伐，不断学习和适应新的技术变化，就能轻松应对各种挑战。