webpack
前置
基础
"webpack": "^5.72.0",
"webpack-cli": "^4.9.2",
"webpack-dev-server": "^4.9.0"
mini-svg-data-uri. : 最小化 SVG 文件需要安装一个第三方库,
mini-css-extract-plugin： 替代 style-loader
css-loader & style-loader & sass-loader & less-loader & postcss-loader
html-webpack-plugin
clean-webpack-plugin
devServer
hot: true, // 开启热更新
或者 new webpack.HotModuleReplacementPlugin() //
if (module.hot) {
module.hot.accept("./components/header.js", () => {});
}
static: path.join(__dirname, 'dist'), // 注意：Webpack5 中已用 static 替代 contentBase
publicPath: '/' // 服务器访问静态资源的默认路径，优先级高于 output.publicPath
babel
babel-loader @babel/core @babel/preset-env
core-js@3
babel/plugin-transform-runtime
@babel/runtime
@babel/runtime-corejs3
thread-loader
缓存
缓存：
babel缓存
cacheDirectory: true
--> 让第二次打包构建速度更快
文件资源缓存
hash: 每次wepack构建时会生成一个唯一的hash值。
问题: 因为js和css同时使用一个hash值。
如果重新打包，会导致所有缓存失效。（可能我却只改动一个文件）
chunkhash：根据chunk生成的hash值。如果打包来源于同一个chunk，那么hash值就一样
问题: js和css的hash值还是一样的
因为css是在js中被引入的，所以同属于一个chunk
contenthash: 根据文件的内容生成hash值。不同文件hash值一定不一样
--> 让代码上线运行缓存更好使用
optimization 生产环境才有意义
splitChunks: {
chunk: 'all' , 对代码进行分割
runtimeChunk：true // 代码分割时一定要使用 runtimeChunk, 否则将导致缓存失效
minimize: true,
minimizer: [
new TerserPlugin({
parallel: true // 使用多进程并发运行以提高构建速度
并发运行可以显著提高构建速度，因此** 强烈建议添加此配置 ** 。
})
]
}
// 默认值存在的问题是：比如打包
main和utils.js时， main中记录着 utils 的 hash值，导致缓存失效使用： runtimeChunk: "single",
oneOf只会匹配一个loader, 不用每次都走完全部的loader- 多个
loader用use, 单个loader 用 loader - Loader 的作用是将不同的资源进行转换，那么 Plugin 则是在打包的过程中帮我们做一些事情，使打包过程更好管理。
当你运行 npm run bundle 时，它会先去 node_modules 文件夹中去找是否安装了 webpack 这个指令，如果有就会执行了，相当于被翻译成了 webpack 这个命令。
也就是看 node_modules 中的 webpack 下的 bin 中是否有对应的可执行指令文件
- SVG 文件转换为 URI 编码后，与 base64 相比，体积会更小；
- 处理 txt、xml 文件
type: 'asset/source'更好，它会导出资源的源码，这样就能看到全貌，而非 base64 格式的编码字符串。
4与5的不同
根据 Webpack5 的文档，它简化了之前版本对于文件方面的配置，提供了 Asset Modules （静态资源模块)，替代了之前常用的 raw-loader、url-loader、file-loader。
Webpack5 中已用 static 替代 contentBase
asset 类型
当 type 设置为'asset'，就会按照以下的策略去打包文件：
- 如果一个模块大小超过 8 kb（这个值是默认的），就使用
asset/resource，被打包进输出文件夹中。（类似于 file-loader） - 否则，就使用
asset/inline，内联到打包文件中。(类似于 url-loader)
区别在于：前者会被单独放进输出文件夹中，后者被处理成 base64 编码字符串内敛进打包出的 JS 文件中。
后者的好处在于减少一次 http 请求，但是过长的字符串也会加重 js 的体积导致加载变慢，因此需要根据实际情况来确定到底采用哪一种方式去处理文件。
注意，当被作为后者处理时，是可以设置编码方式的，例如上面提到的特殊处理
手动通过 Rule.parser.dataUrlCondition.maxSize 去设置两者的界限：
module.exports = {
mode: 'development',
devtool: 'eval-cheap-module-source-map' // development
}
module.exports = {
mode: 'production',
devtool: 'nosources-source-map', // production
}
\
