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

Question

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

试试 app

查看 source

您可以交互查看results webpack-bundle-analyzer，这里是一个快照:



我不明白为什么@material-ui/core/es出现在两个 node_modules和 src .更一般地说，我试图了解我们的 tree-shaking 是否得到了最佳实现，或者是否有更好的配置方法。如果我们最好地摇树，我也会很感激。 (请注意，我们只针对常青浏览器。)

请随时 fork repo并编辑 webpack.config.prod.js .如果您打开拉取请求，Netlify 将构建和部署一个测试服务器，您可以在 test-server-url /report.html 下查看结果.

Answer 1

所以让我先说es名字选得不好。 src会更合适，因为它只是:未编译的源代码。这记录在 the docs under minimizing bundlesize

使用 webpack 4 和正确的 module相应的 package.json 中的条目您应该自动提取这些包的 esmodule 版本。 esmodule 版本负责 webpack 中大部分的 tree-shaking 优化。
@material-ui/core已经有一个正确的条目。然而，这只是顶层的 esmodule 版本。然后使用不允许在 webpack 中进行 tree-shaking 的 commonJS 编写实际的组件。我们有一个 open PR但是我们可能会等待下一个专业，因为我们不对编译文件进行测试，这会使构建的更改变得可怕。

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

总的来说，我建议不要使用 es版本并简单地让 webpack 以 module 为目标入口。它允许对大部分包进行摇树，但您会在一些微优化上松懈。我测试了将所有内容转译为 esmodules，并对捆绑包的 stat 大小从 200KB 到 180KB 进行了一些改进，但遇到了一些 gzip 去优化，将 gzip 压缩后的大小增加了 1KB (meme version)。所以不要为每个小文件都担心摇树。