在闭包编译器中连接和编译丑陋的 javascsript答案

【问题标题】：Concatenating and compiling uglified javascsript in closure compiler在闭包编译器中连接和编译丑陋的 javascsript
【发布时间】：2013-10-30 06:35:04
【问题描述】：

对于一些 javascript 包，我只能得到缩小/丑化的文件。我需要将它们与我的其他 javascript 文件结合起来，并使用 google 闭包编译器进行编译。

我的问题是：

是否最好将原始未缩小的 javascript 传递给闭包编译器，而不是丑陋的？（尤其是高级优化模式。）

由于许多 javascript 库本身提供了缩小版本（如 jquery 和 angularjs），如果我将这些脚本包含在另一个缩小任务（uglify 或闭包编译）中，我是否需要担心。还是我应该将它们单独列出并仅将它们连接起来？

【问题讨论】：

如果浏览器能够理解缩小的脚本，那么声称是 JS“编译器”的工具也应该如此。唯一可能出现的问题是，如果不同的缩小脚本要使用同名的全局变量……因为缩小通常包含将变量重命名为“短”名称，如a、b 等，这可能会发生。但是好的脚本无论如何都不会使用全局变量，对吧？

标签： javascript gruntjs google-closure-compiler

【解决方案1】：

如果你喜欢微优化，你可能想看看几个缩小器，看看哪个最适合你的代码库。主要有 UglifyJS、Google Closure Compiler 和 ESMangle。有一个nice comparison on the Uglify website。通过几个 minifier 运行代码可能看起来有点矫枉过正，但如果它产生更好的结果，那为什么不呢。 :-)

缩小器不关心你是否传入已经被缩小的东西；作为一个例子，我在生产中使用了 r.js 优化器，它将我的未缩小的源代码和缩小的 jQuery 等连接起来，然后将整个代码都丑化了。

您不必真正担心重新压缩库，它所要做的就是在构建步骤上增加更多时间，因此如果花费的时间太长，那么您可以将库从压缩器中分离出来并简单地连接它们。

【讨论】：

这对于 Closure-compiler 是不正确的。 Closure-compiler（包括类型检查、静态分析和死代码消除）的好处不仅仅是缩小。通过它运行已经缩小的代码并不是它的设计目的，也不会得到很好的结果。

【解决方案2】：

根据库有两种路径：

如果库提供未压缩的源并且已知它与ADVANCED_OPTIMIZATIONS 兼容，那么最好的选择是将其作为源文件传递。此选项可从库源代码和您的源代码中消除死代码。
如果库只提供缩小源或已知与ADVANCED_OPTIMIZATIONS 不兼容，那么最好的选择是使用库的外部编译代码。为了尽量减少请求的数量，您仍然应该将结果连接在一起。虽然您可以使用编译器的WHITESPACE_ONLY 级别，但它可能不是最好的工具。

当然，将库与您的源相结合会最大限度地减少请求，但同时会抵消使用 CDN 托管库所带来的任何缓存优势。

【讨论】：