我一直在努力寻找将 webpack 实施到现有大型 Django 项目的前端工作流程中的最佳方法。
我的两个主要担忧是：
webpack 输出的捆绑文件会污染全局命名空间，可能会在现有客户端脚本之间造成命名冲突。
捆绑的文件将是非常大的有效负载，加载时间过长。
通常项目被分解为应用程序。为每个应用提供特定的捆绑文件可能更有意义。
对任何其他想法持开放态度。非常感谢您的帮助！
【问题讨论】：
标签： django webpack ecmascript-6 frontend large-files
Webpack 主要是一个模块加载器。这意味着它使用的源应该是具有隔离范围、依赖项和导出的模块。除非您通过将某些内容分配给全局范围或加载不支持模块的源来显式泄漏某些内容，否则您不应该担心加载的脚本在文档中发生冲突。例如，如果您要加载一个 Webpack 脚本以在 Django Admin 中运行，那么您在 Webpack 源代码中看到的 jQuery 版本是您与 Webpack 捆绑的版本，而不是与 Django 一起分发的版本
Webpack 在构建过程中提供了一种先进的code-splitting 技术，它会分析你的模块的依赖关系图并将你的构建分解成更小的块，可以按需异步加载，所以如果你的应用程序被分解成应用程序 em>，那么您可以拥有 per-app 组块，这些块仅在用户使用某个应用程序时才加载，并推进到某个点。
最后，如果您使用提供的optimization options 进行生产，您看到的捆绑文件的大小可能会减小。我还建议您现在尝试webpack@beta，支持tree-shaking，当您仅使用可能具有较大依赖关系图的部分库时，这将减少输出包。
【讨论】：