在部署之前你对你的 JavaScript 代码做了什么？答案

【问题标题】：What do you do to your JavaScript code before deployment?在部署之前你对你的 JavaScript 代码做了什么？
【发布时间】：2010-10-31 10:43:26
【问题描述】：

在您的部署过程中，您是否有缩小 JS 的步骤？您是否有任何类型的 JavaScript 预处理器允许您留在 cmets 和 console.logs 中，然后自动删除它们？你的 JavaScript 机器是由 GWT 还是 Script# 生成的？您是否使用 ANT 或其他工具来自动化部署？

我看到很多 JavaScript 看起来像是直接从编辑器中出来的，包含大量空白和 cmets。其中有多少是由于不关心已部署代码的状态，又有多少是由于开放网络的精神？

【问题讨论】：

如果您担心压缩率，此页面很好地概述了一些工具与一些最流行的 javascript 库实现的比率：compressorrater.thruhere.net。
我最近从“最佳实践”的角度想知道这个问题。我的 IT 极客说 Web 服务器应该处理压缩，而不是开发人员。我在 mootools 上进行了一些廉价的分析，发现使用 YUI 或其他任何方法进行预压缩会比标准 gzip 产生边际大小的改进，而标准 gzip 正是 Web 服务器将使用的。但是，这样的利润是否值得为“开放网络精神”带来麻烦和潜在的冒犯？
@Ben Dunlap：那是你同时做的时候：缩小和 gzip。您可以使用生产构建脚本进行压缩，服务器会为您处理 gzip。
@dalbaeb，是的，我知道——这正是我正在测试的；抱歉，如果不清楚。我采用了缩小版的 mootools 并对其进行了 gzip 压缩，然后将结果与 mootools 原始版本的 gzip 进行了比较。差别很小，所以我的问题是：如果网络服务器无论如何都应该压缩所有响应，那么缩小我能得到什么？因为我知道我通过缩小而失去：第三方读者的代码清晰度，以及我的时间（当我必须对发布代码进行更改时）。我想我正在尝试进行成本/收益分析。
通过缩小获得什么取决于您拥有多少代码。即使具有较短的变量/函数名称有时也可以减少整体大小和下载时间。我们在这里谈论毫秒，这是真的。但是用户等待的时间越少越好。此外，如果您只是为了生产而缩小，您仍然可以使用可读的“开发”版本。第三方读者的清晰度 - 是的，这会受到影响。同样，这取决于它对您的价值。

标签： javascript deployment release-management minify

【解决方案1】：

我通常使用JSLint 检查它以确保它没有错误，然后使用YUI compressor 对其进行打包/编码。

【讨论】：

请注意，但 JSLint 实际上并没有从操作的角度检查脚本以确保它是错误的（例如，范围测试正在检查正确的范围），而是仔细检查语法以使确定你没有做错任何事。

【解决方案2】：

我的步骤包括：

我使用安装了 Javascript 工具包的 TextMate 编写 Javascript。这个 JSLint 是我每次保存时的文件，并在发生错误时通知我。
我使用 Sprockets 自动连接我的各种 Javascript 文件。
我通过 jsmin 运行生成的串联以生成缩小版本。

我最终得到一个串联的 lib.js 文件和一个缩小的 lib.min.js 文件。一个用于开发，一个用于生产。 TextMate 命令有助于实现这一切的自动化。

我仍在寻找一个好的解决方案来实际（单元）测试我的脚本。

【讨论】：

我必须了解 Ruby 才能使用 Sprockets 吗？或者我可以安装 Ruby 并学习 Sprockets？
@Nosredna：你不必了解 Ruby，但它有助于定制它。我从 Ruby 脚本调用 Sprockets，但它也有一个命令行工具。
附带说明，TextMate 的“等效”窗口是 e-texteditor，它也对文件进行 jslints。

【解决方案3】：

查看YUI Compressor，它是一个控制台应用程序，您可以使用它来缩小（去除 cmets、空格等）并混淆您的 javascript 文件。

【讨论】：

【解决方案4】：

JSMin 来自道格拉斯·克罗克福德。我们已将它连接为 Studio 中的宏以及我们一些大型项目的后期构建项目

【讨论】：

【解决方案5】：

FWIW，这里有一个有趣的迷你基准，介绍了您可以最小化 Javascript 源代码的各种方法：

http://www.ericmmartin.com/comparison-of-javascript-compression-methods/

简而言之：

HTTP 协议中的 gzip 压缩确实有所作为（尽管您需要在服务器端支付 CPU 成本）
缩小（删除空格/cmets，更改变量名等）也有帮助，如果你想要最好的结果，可以将它与 gzip 压缩一起使用
基于 js 的解压缩器很可能没有用 - 虽然您可能会获得较小的大小，但客户端上的 CPU 开销很大。

【讨论】：

【解决方案6】：

对于我们的一款产品，我们将所有 Javascript 文件连接在一起（大多数文件在大多数页面上使用，因此这对我们来说很有意义）并使用 Javascript::Minifier。这给了我们相当不错的速度提升。

【讨论】：

【解决方案7】：

其中很大一部分可能是由于不关心可能在速度较慢且连接速度较慢的机器上查看您的页面的人，并假设每个人都有 50Mbps 的线路和 3 Gigs 的 RAM。

作为 .NET 环境中构建过程的一部分，我们正在缩小（手写 + 插件、jQuery 等）JS。没有预处理器，一旦时间允许，这是我们绝对应该做的事情。

附：顺便说一句，我们没有使用 console.log，因为这会破坏 IE。相反，我们有一个简单的包装函数，例如：

function log(stuff) {
    if (window.console && window.console.log) {
        console.log(stuff);
    }
};

【讨论】：

您正在编写什么样的 JavaScript 库，其中 minify 实际上会对最终用户的可用 RAM 产生重大影响？
是的，这是真的，对不起。请忽略 RAM 位。缩小当然对RAM没有影响，我只是无缘无故地把写高质量代码的事情扔了进去。

【解决方案8】：

我有一个 PHP 脚本，它在服务器端执行它并保留它从源文件夹中提取的任何内容的缓存。

【讨论】：

【解决方案9】：

一句话-packer

【讨论】：

大多数库已经从打包器转移到带有 gzip 的压缩器。 Packer 在代码自行解包时占用了宝贵的时间。

【解决方案10】：

点燃一根蜡烛，为 IE6 错误祈祷，然后单击“开始”。这算不算？ :)

【讨论】：

是的，但我认为你需要比耳语更强大的东西来处理 IE6。

【解决方案11】：

我不会缩小我自己的 JavaScript 代码，因为文本倾向于很好地 gzip/压缩。
我会缩小一个非常大（比如 > 100 kb）的 javascript 库（但我可能不想再使用这么大的库（或者只是发布我使用的库）。

我倾向于认为，很多 javascript 缩小（实际上）是为了实现 javascript 代码的某种（徒劳的）混淆，而不是宣称的最终用户性能提升。

【讨论】：

如果代码中有很多 cmets，可以使用 minify 作为一个方便的 cmets 剥离器。

【解决方案12】：

还有a .NET port of YUI Compressor 可以让你：-

将缩小/文件合并到 Visual Studio 构建后事件中
集成到 TFS 构建（包括 CI）
如果您只想在自己的代码中使用 dll（例如，即时缩小）。

【讨论】：

【解决方案13】：

我想我会分享我的 js 部署方法。看看这篇博文： http://www.picnet.com.au/blogs/Guido/post/2009/12/10/Javascript-runtime-compilation-using-AspNet-and-Googles-Closure-Compiler.aspx

这还包括在运行时（需要时）编译（使用 google 的闭包编译器）的代码。

谢谢吉多

【讨论】：