Cloud Native Interactive Landscape 是一个开源、仅浏览器的应用程序，它加载一个静态 React 应用程序以可视化云原生生态系统：
你可以交互式地查看 webpack-bundle-analyzer 的结果，这里是一个快照：
我不明白为什么@material-ui/core/es会同时出现在node_modules和src中。更一般地说，我试图了解我们的 tree-shaking 是否得到了最佳实施，或者是否有更好的配置方法。如果我们最好地摇树，我也会很感激。（请注意，我们只针对常青浏览器。）
请随时 fork回购并编辑webpack.config.prod.js。如果您打开一个拉取请求，Netlify 将构建和部署一个测试服务器，您可以在test-server-url/report.html下检查结果。
所以让我先说这个es名字选得不好。src会更合适，因为它只是：未编译的源代码。这记录在最小化捆绑包大小下的文档中
使用 webpack 4 和module相应的适当条目，package.json您应该自动提取这些包的 esmodule 版本。esmodule 版本负责 webpack 中大部分的 tree-shaking 优化。
@material-ui/core已经有一个正确的条目。然而，这只是顶层的 esmodule 版本。然后使用不允许在 webpack 中进行 tree-shaking 的 commonJS 编写实际的组件。我们有一个开放的 PR，但我们可能会等待下一个专业，因为我们不对编译文件进行测试，这会使构建的更改变得可怕。
至于为什么这显示为串联模块，我无能为力。在调查时，我做了同样的观察（https://github.com/eps1lon/material-ui-treeshaking）。这可能是 bundle-analyzer 的问题，对生成的块没有实际影响（例如https://github.com/webpack-contrib/webpack-bundle-analyzer/issues/188）。
总的来说，我建议不要使用该es版本，而只是让 webpack 以module条目为目标。它允许对大部分包进行摇树，但您会在一些微优化上松懈。我测试了将所有内容转译为 esmodules，并对捆绑包的 stat 大小从 200KB 到 180KB 进行了一些改进，但遇到了一些 gzip 去优化，这将 gzip 压缩后的大小增加了 1KB（meme 版本）。所以不要为每个小文件都担心摇树。