为什么Webpack 4树摇动后，material-ui模块会同时显示在node_modules和src中？

Question

Cloud Native Interactive Landscape是一个开放源代码的，仅用于浏览器的应用程序，可加载静态React应用程序以可视化云原生生态系统：

• 试用应用
• 查看资料

您可以交互式查看webpack-bundle-analyzer 的结果，这是一个快照：

我不明白为什么@material-ui/core/es在node_modules和中都出现src。更笼统地说，我试图了解是否以最佳方式实现了摇树，或者是否有更好的配置方法。如果我们最喜欢摇摇晃晃的lodash，我也将不胜感激。（请注意，我们只针对常绿的浏览器。）

请随时分叉存储库并编辑webpack.config.prod.js。如果打开请求请求，Netlify将构建并部署测试服务器，您可以在test-server-url下检查结果/report.html。

Answer 1

因此，让我先说明一下，这个es名字选得不好。src会更合适，因为它只是：未转换的源代码。这在最小化捆绑包大小下的文档中有记录

使用 webpack 4 和module相应的正确条目，package.json您应该自动提取这些包的 esmodule 版本。esmodule 版本负责 webpack 中的大部分 tree-shaking 优化。

@material-ui/core已经有一个正确的条目。然而，这只是顶层的 esmodule 版本。然后，实际的组件是用 commonJS 编写的，它不允许在 webpack 中进行树摇动。我们有一个开放的 PR，但我们可能会等待下一个重大项目，因为我们不会对编译的文件进行测试，这会使构建的更改变得可怕。

至于为什么这显示为串联模块，我无法帮助您。在调查时我也做了同样的观察（https://github.com/eps1lon/material-ui-treeshaking）。这可能是捆绑分析器的问题，对生成的块没有实际影响（例如https://github.com/webpack-contrib/webpack-bundle-analyzer/issues/188）。

总的来说，我建议不要使用该es版本，而只是让 webpack 定位该module条目。它允许对包的大部分进行树摇动，但你会失去一些微观优化。我测试了将所有内容转译为 esmodules，并对捆绑包的统计大小从 200KB 改进为 180KB，但遇到了一些 gzip 去优化，导致 gzip 压缩大小增加了 1KB（meme 版本）。因此，不必担心每个小文件的树摇动。