我有一个 ClojureScript 应用程序，它使用 Google 的 Closure Compiler 作为编译器后端。使用高级优化生成的捆绑包似乎太大了。我责怪依赖关系，但我如何找出哪些模块在输出包中占用最多的字节？我浏览了所有 Closure Compiler 选项，没有发现任何有用的东西。然后我尝试了解源映射并使用它来计算单个模块的大小，但没有成功。
我想要一个树状输出，我可以在其中挖掘并找到最大的模块，例如。
goog 100kb
goog.net30kbreact90kbmy 50kb
my.namespace30kb【问题讨论】：
标签： javascript compilation clojurescript google-closure-compiler
shadow-cljs 可以生成Build Reports，它采用高级编译输出并分析源映射，然后将其与一些编译器信息结合起来，按工件等对源进行分组。报告生成为独立的 .html 文件。
可以在here 找到示例构建报告。该构建包含来自npm 的"antd" 包。可以在here 找到刚刚包含"antd/es/button" 的比较报告。
请注意，这仅限于 shadow-cljs，因为它依赖于所有可用的源地图数据。分析其他工具生成的 CLJS 构建的源映射会遗漏所有 CLJSJS 内容的源映射，因此会包含很多“空白”。
【讨论】：
cljs.build.api 并因此使用相同的编译器选项，而且我看不到任何可以为我提供一些额外见解的东西。此外，如果您可以命名其他一些不完全传播源地图数据的构建工具，那将是很酷的，为什么？我不热衷于切换构建系统，但我想要那个构建报告:)
cljs.build.api 公开的数据要多得多。任何使用 CLJSJS 的东西都不会有准确的源地图数据，因为这些包不包含任何源地图。 shadow-cljs 不使用 CLJSJS，而是直接访问 npm 包，并在处理它们时生成 source map 数据。
据我所知，不存在这样的工具。不过，这将是一个很好的选择。
该工具不必特定于 Closure Compiler。相反，分析输出源映射可以将代码中的特定符号归因于特定的输入文件。
【讨论】：