清理代码

使用 ​/* webpackChunkName: '...' */​ 时

请确保你了解了其含义图：

• 此处 chunk 的名称本意是 public 的。
• 它不仅是用于开发模式的名称。
• webpack 会在 production 以及 development 的模式中使用它对文件进行命名。
• 即使用不使用 ​webpackChunkName​，webpack 5也会自动在 ​development​ 模式下分配有意义的文件名。

为 JSON 模块使用工具名称导出

新规中将不再支持下面这种方式，如此做会发出警告：

import { version } from './package.json';
console.log(version);

请使用如下方式替代：

import pkg from './package.json';
console.log(pkg.version);

清理构造代码

• 当使用 ​const compiler = webpack(...);​ ，确保在使用完成后，使用​compiler.close(callback);​ 关闭编译器。
• 这不适合用于自动关闭的 ​webpack(..., callback)​ 。
• 如果你在监听模式下使用webpack，直接连接到用户绑定进程，此可选。在监听模式下面的空闲阶段将被用于执行此操作。

运行单个结构并遵循以下建议

请事务必须仔细阅读构建时的错误/警告。如未发现相关建议，请创建一个issue，我们将尽全力解决。

重新按照下面步骤，直到你至少解决到 Level 3 或 Level 4：

• Level 1: 模型（Schema）校试失败。

配置选项已更改。应该要有校试失败的信息并附上 ​BREAKING CHANGE:​ 提示，或提示应用哪一个选项。

• Level 2: webpack 异常退出并出现错误。

错误信息告诉你哪里需要进行修改。

• 等级3：构建错误。

错误信息应该要有 BREAKING CHANGE: 提示。

• Level 4: 构建警告。

警告信息应该告诉你哪里需要进行修改。

• Level 5: 运行时错误。

这很棘手，你可能需要调试才能找到问题所在。在这里很难给出一个通用的建议。但是我们在下面列出了一些关于运行时错误的常见建议：

1. ​process​ 未定义。

• webpack 5 不再引入 Node.js 变化的 polyfill，在前端代码中应用避免免费使用。
• 想支持浏览器的使用方法？使用 ​exports​ 或 ​imports​ 中的 package.json字符串，会根据环境不同使用不同的代码。

• 也可以使用 ​browser​ 字段来支持旧的 bundlers。
• 替代方案。用 ​typeof process​ 检查包裹的代码块。请注意，这将对 bundle 大小产生负面影响。

• 使用环境变量，如 ​process.env. VARIABLE？​你需要使用 ​DefinePlugin​ 或者  ​EnvironmentPlugin​ 在配置中定义这些变量。

• 考虑使用 VARIABLE 代替，但需要检查 ​typeof VARIABLE !== 'undefined'​ 。​process.env​ 是 Node.js 特有，应避免在前端中使用。

2. 404错误将指向包含 auto 的 URL 

• 并非所有生态系统工具都已设置好的新 ​publicPath​ 的默认值 ​output.publicPath: "auto"。

• 使用静态的 ​output.publicPath: ""​ 代替。

• Level 6: 弃用警告。

你可能会收到很多弃用警告，插件需要时间来赶上内部的变化。请将这些弃用上报给插件。这些弃用只是警告，构建仍然可以正常工作，只是会有小瑕疵（比如性能降低）。

1. 你使用带有 ​--no-deprecation​ 选项的 node 运行 webpack ，可以可以隐藏废弃告警，例如：  ​node --no-deprecation node_modules/webpack/bin/webpack.js​ 。但这只能作为临时的解决方案。
2. plugin 和 loader 的开发者，应遵循弃用信息中的建议以改进代码。

• Level 7: 性能问题。

一般来说，webpack 5 的性能应该会有所提高，但也存在少数情况性能会变差。

而在这里，你可以做一些事情来改善这种情况：

1. 通过 Profile 检查时间花费在哪里。

• ​--profile --progress​ 可以显示一个简单的性能目标。
• ​node --inspect-brk node_modules/webpack/bin/webpack.js + chrome://inspect ​/  ​edge://inspect​  。

• 你可以将这些性能文件保存到文件中，并在 issues 中提供它们。
• 尝试使用 ​--no-turbo-inlining​ 选项，在某些情况下可以获得更好的堆栈信息。

2. 在增量构建时，构建模块的世界可以通过使用像 webpack 4 中的不安全缓存来改善：

• ​module.unsafeCache: true​ 
• 但是这可能会影响处理代码库的一些变化能力。

3. 全量构建

• 与新功能相比，弃用特性的向后兼容层通常性能很差。
• 创建许多警告会影响构建性能，即使它们被忽略。
• Source Maps 的代价很昂贵。请在文档中查看 ​devtool​ 选项以比较使用不同选项的代价。
• Anti-Virus（反病毒）保护可能会影响文件系统的访问性能。
• 持久缓存可以帮助改善重复性的完整构建。
• Module Federation 允许将应用程序分割成多个较小的构建。