一、配置文件
webpack 提供的 cli 支持很多的参数，例如 --mode 。在我们平时的开发过程中，我们要学习很多的功能，这些很多都是可以用参数来完成的。那么后边就会导致参数越来越多，我们使用命令特别的不方便，所以我们会使用一种更加灵活的方式---配置文件。
1. webpack 配置文件
- 配置文件的基本使用
默认情况下，webpack 会读取 webpack.config.js 文件作为配置文件，但也可以通过 cli 参数 --config 来指定某个配置文件，例如 npx wenpack --config abc.js。
2）配置文件的编写规范
- 导出方式：必须使用 CommonJS 模块规范导出配置对象，即 module.exports = {...} 。不能使用 ES6 的 export default 语法，会导致 webpack 无法识别配置。
- 配置优先级：当命令行参数与配置文件冲突时，命令行参数优先级更高
3）常见配置属性
学习 webpack 简单的来说就是学习配置文件有哪些东西可以配置。有了配置文件就可以在配置文件配置属性，而不需要再在命令行配置了。
- mode：编译模式，字符串，取值为 development 或 production ，指定编译结果代码运行的环境，会影响 webpack 对编译结果代码格式的处理
- entry：入口文件配置，字符串，指定打包的起点
- output：出口配置，对象，指定打包结果的文件名和路径，指定编译结果文件
4）配置文件注意事项
配置文件中的代码必须是有效的 Node.js 代码，而且自定义配置文件路径必须正确，否则会报 MODULE_NOT_FOUND 错误。
webpack 支持多模块化，为什么配置文件里边只能用 commonjs 导出，而不能用 ES6 呢？
webpack 支持多模块化指的是它在构建依赖关系的时候，无论用 commonjs 还是 es6 它都能识别到。为什么在配置文件里边识别不了是因为 webpack 在打包过程中或说是在编译过程中，它是在 node 环境，在这个编译的过程它要读取配置文件的内容，而 nodejs 原生支持 CommonJS。
5）配置文件与源代码的关系
- 打包结果独立性：dist 目录产物完全独立，不依赖原始配置文件，可脱离项目目录单独运行打包结果。
- 关键区别：
-
- 配置文件：参与打包过程执行，决定打包行为
- 源代码：仅提供内容素材，不影响打包过程本身
2. 配置文件的基本配置
1）mode
- 配置方式：可通过CLI参数--mode或配置文件设置，推荐使用配置文件
- 优先级规则：当命令行参数与配置文件冲突时，以命令行参数为准
- 可选值：
-
- development：开发环境，代码不压缩
- production：生产环境，代码会进行优化压缩
- 实践技巧：可在package.json中配置不同脚本，如"dev": "webpack"和"build": "webpack --mode=production"
2）entry
- 默认值：./src/index.js
- 修改方式：在配置文件中通过entry属性指定
- 路径规则：需使用相对路径，从配置文件所在目录开始计算
- 注意事项：修改入口文件后需确保文件存在，否则会报错Can't resolve './src'
- 成功打包后生成对应的输出文件
3）output
- 默认输出：./dist/main.js
- 配置结构：output是一个对象，包含多个配置属性
- 常用属性：
-
- filename：指定输出文件名
- 保留机制：修改输出文件名后，旧文件不会被自动删除
3. 配置文件的总结
a. 1）配置文件的运行环境
- 参与打包过程：配置文件在打包过程中会参与运行，其导出的结果将影响整个打包流程。
- Node环境要求：由于运行环境是Node环境，因此配置文件中参与打包过程运行的代码必须是Node代码。
b. 2）源代码处理机制
- 源代码读取方式：webpack通过入口文件读取源代码，但仅分析代码内容而不执行。
- 模块化兼容性：源代码中可以使用任意模块化规范（如CommonJS/ES Module等），因为webpack只进行依赖分析。
c. 3）打包过程与运行时的区别
- 错误发生时机：
-
- 打包阶段：不会执行源代码，因此语法错误不会导致打包失败（如a.abc()调用null值）
- 运行阶段：打包后的代码在浏览器/Node环境执行时才会暴露运行时错误
- 配置文件特殊性：与源代码不同，配置文件中的代码会在打包时立即执行，因此必须保证语法正确。
二、devtool配置
1. source map源码地图
前端开发中源代码经过合并、压缩、转换后运行，导致报错时难以定位原始代码位置。source map仅解决调试问题，与webpack无关，是独立技术。其核心功能是将转换后代码映射回源代码，不影响实际运行结果。source map 无兼容性问题，因为调试仅面向开发者（使用现代浏览器），普通用户不会触发调试功能。
1）浏览器处理source map的原理
- 文件结构：
-
- 转换后代码：如bundle.js，末尾包含注释//# sourceMappingURL=bundle.map指定映射文件
- 映射文件：记录原始代码内容及与转换代码的精确对应关系
- 工作流程：
-
- 浏览器请求并执行转换后代码
- 发现source map注释后自动请求映射文件
- 报错时通过映射关系显示原始代码错误位置
- 技术本质：映射文件是独立配置文件，不参与代码执行，仅提供调试时的代码映射服务。
2）使用source map的最佳实践
- 开发环境：
-
- 必要性：必须启用，提供完整调试支持
- 优势：快速定位合并/压缩后的代码错误源头
- 生产环境：
-
- 风险1：显著增加网络传输量（映射文件体积较大）
- 风险2：暴露原始代码（可通过工具从映射文件还原源码）
- 特殊需求：若需调试生产环境问题，应对映射文件进行特殊处理（如限制访问、混淆等）
- 核心原则：source map是纯调试工具，不应影响生产环境性能和安全性
2. 构建示例
1）开发环境调试
- 开发环境配置：
-
- 新建webpack.config.js文件，设置mode: "development"
- 默认使用eval方式运行代码，浏览器会通过注释识别源码位置
- 错误信息会显示在原始文件位置而非打包后文件
- eval模式特点：
-
- 代码通过eval()执行，末尾添加//# sourceURL注释
- 浏览器调试时会根据注释将代码归类到虚拟文件结构中
- 对实际运行无影响，仅用于调试目的
- 开发环境默认使用此方式
- 调试体验：
-
- 错误信息直接定位到源文件位置
- 浏览器显示webpack://虚拟目录结构
- 可查看原始代码而非转换后的代码
2）生产环境问题
- 生产环境配置：
-
- 设置mode: "production"
- 默认使用none模式（不生成source map）
- 错误信息直接显示在打包后的代码中
- 调试困难：
-
- 错误信息指向压缩后的代码行
- 无法直接关联到原始源文件
- 难以定位和修复问题
- devtool关键配置：
-
- none：不生成source map（生产环境默认）
- eval：使用eval执行（开发环境默认）
- source-map：生成独立source map文件
- eval-source-map：最佳开发环境品质
- cheap-module-eval-source-map：平衡速度与准确性
- 配置建议：
-
- 开发环境：使用eval-source-map或cheap-module-eval-source-map
- 生产环境：使用source-map并确保服务器安全配置
- 避免同时使用devtool选项和SourceMapDevToolPlugin插件
3.devtool配置
1). eval-source-map
- 执行方式: 每个模块使用eval()执行，source map转换为DataUrl后添加到eval()中
- 构建特点:
-
- 初始化source map时比较慢
- 重新构建时速度较快
- 会生成实际文件
- 映射精度:
-
- 行数能够正确映射到原始代码
- 生成开发环境最佳品质的source map
- 推荐场景: 开发环境首选配置
- cheap-eval-source-map特点:
-
- 类似eval-source-map但只映射行数
- 不生成列映射(column mapping)
- 忽略loader的source map
- 仅显示转译后的代码
- 缺点:
-
- 错误定位不够精确
- 同一行长代码中无法准确定位错误位置
2). 开发环境
- eval-source-map优势:
-
- 准确对应源代码
- 能定位行和列的错误
- 文件体积适中
- source-map单独文件:
-
- 生成独立.map文件
- 构建速度较慢
- 通过//# sourceMappingURL注释引用
- 调试时可查看完整源代码和生成代码的对应关系
3). 开发环境和生产环境
- 生产环境默认建议:
-
- 不使用source map是最佳选择
- 必须使用时的方案:
-
- 配置服务器禁止普通用户访问.map文件
- 仅开发者通过特殊方式获取source map
- 避免网络传输开销和代码暴露风险
4). 生产环境
- hidden-source-map特点:
-
- 生成source map但不添加引用注释
- 对用户隐藏但文件实际存在
- 需要特殊工具才能读取
- 适用场景:
-
- 生产环境调试需求
- 需要保护源代码不被轻易获取
- 通过专业工具进行错误分析