如何分析Closure Compiler打包大小

Question

我有一个ClojureScript应用程序，使用Google Closure Compiler作为编译器后端。使用高级优化的结果捆绑似乎太大了。我认为是依赖关系导致的，但我如何找出输出捆绑包中占用最多字节的模块？我浏览了所有Closure Compiler选项，没有找到任何有用的信息。然后我尝试学习源映射并使用它来计算单个模块的大小，但没有成功。

我希望得到一种树状输出方式，可以挖掘出按大小排序的最大模块，例如：

[+] goog 100kb [+] goog.net 30kb [+] react 90kb [+] my 50kb [+] my.namespace 30kb

- skrat

Answer 1

shadow-cljs可以生成构建报告(Build Reports)，该报告会获取高级编译输出并分析源映射，然后结合一些编译器信息将其按工件进行分组等。报告将作为独立的 .html 文件生成。

这里可以找到一个样本构建报告 here。构建过程包括从 npm 中使用"antd"包。还有一个比较报告仅包含"antd/es/button"，可以在此处找到: here。

请注意，这仅限于 shadow-cljs，因为它依赖所有源映射数据。分析其他工具生成的 CLJS 构建的源映射会错过所有 CLJSJS 内容的源映射，因此会包含很多“空白”。

- Thomas Heller

---

你能具体说明一下什么是“一些编译器信息”吗？我不熟悉shadow-cljs，但我假设它使用cljs.build.api，因此使用相同的编译器选项，而我没有看到任何可以为我提供额外见解的选项。另外，如果您能提供一些其他不完全传播源映射数据的构建工具和原因，那就太棒了！虽然我不想切换构建系统，但我想要那个构建报告 :) - skrat

shadow-cljs 与 CLJS 和 Closure Compiler 紧密地接口，因此它具有比 cljs.build.api 更多的数据。使用 CLJSJS 的任何内容都不会具有准确的源映射数据，因为这些软件包不包含任何源映射。 shadow-cljs 不使用 CLJSJS，而是直接访问 npm 软件包并在处理时生成源映射数据。 - Thomas Heller

Answer 2

据我所知，目前并没有这样的工具。然而有一个这样的工具会非常好。

这个工具不必专门用于Closure Compiler。相反，分析输出源映射可以将代码中的特定符号归属于特定的输入文件。

- Chad Killingsworth

---

我能够使用 https://github.com/danvk/source-map-explorer 得到一些结果，但捆绑包中有相当大的部分无法映射到任何符号。我认为一个合适的解决方案是向Closure Compiler提出一个功能请求。 - skrat

我认为未映射的字节属于前导和外部文件，例如在使用reagent时的React.js。 - skrat

外部文件不应该在捆绑包中。它有多大？你是要找10K还是200K？如果它小于40K，也许未映射的字节只是注入的填充物？尝试将language_out设置为ECMASCRIPT_2017。 - John