css 和 js 文件的缩小应该在构建步骤中还是手动完成？答案

【问题标题】：Should minification of css and js files be in a build step or done by hand?css 和 js 文件的缩小应该在构建步骤中还是手动完成？
【发布时间】：2013-01-13 07:50:27
【问题描述】：

这里真的有两个问题。

1) 缩小应该手动完成还是作为构建的一部分完成？
2) 缩小后的文件是否应该受版本控制？

我正在尝试为我正在处理的当前项目定义前进的道路。我已经进行了一些速度评估，我相信我当前的站点只需添加一些压缩/缩小就可以有很大的性能改进.

这是基本设置

IBM 商务 6.0
大量的大型 js 文件（没有被缩小或压缩）
大量的大型 css 文件（没有被缩小或压缩）

【问题讨论】：

1) 在您的部署中，因为 2) 您不想或不需要对缩小文件进行版本控制，它们是由可读代码制成的不可读代码，在开发中没有用处。跨度>
如果可以在构建中完成，为什么要手动完成？

标签： javascript css minify

【解决方案1】：

您可以使用可以缩小和压缩 JS 和 CSS 的 smartoptimizer

并且可以缓存这个文件，直到文件没有变化。

Download smartoptimizer

该网站项目之一是关于使用 php 压缩和压缩 js 或 CSS。该程序的优点是检测 js 和 css 然后压缩和压缩。如果 js 或 css 更改此程序检测并更新压缩和压缩文件

【讨论】：

该项目与这两个具体问题有何关联？

【解决方案2】：

缩小应该手动完成还是作为构建的一部分完成？

作为构建的一部分。这样你就不会忘记去做。在开发环境中通常不需要缩小代码，如果您发现需要调试仅在缩小代码中显示的问题，则可以手动构建。

您可以在暂存服务器上测试缩小后的代码。

压缩后的文件是否应该进行版本控制？

不是由您的源代码控制。如果您有历史建筑文物的档案，那么它们应该是其中的一部分。

【讨论】：

如果问题只在特定环境中出现怎么办？这并不罕见。
然后“如果您发现需要调试仅在缩小代码中显示的问题，您可以手动构建”（或者您可以手动部署到暂存并禁用缩小步骤）
我猜你可以，但它增加了流程的更多步骤。假设您修复了问题，重新部署到测试环境并在一天后发现另一个错误。再次手动部署？
是的。请注意，“手动部署”并不意味着“手动复制所有文件并手动设置登台服务器的所有配置”。这意味着“注释掉构建脚本中缩小代码的行，然后以登台服务器作为部署目标运行构建脚本”。（也就是说，如果您的登台服务器上出现那么很多问题，那么您的开发环境就不像您的登台环境了）。

【解决方案3】：

这一切都取决于。

有时根据配置设置即时完成此操作很有用。例如，如果您正在部署到一个测试环境并且您已经缩小了您的 JS 并发现了一个仅在该环境中发生的错误，那么轻弹一个开关通常很方便，这样您的应用程序就可以开始提供未缩小的源文件以进行调试。

【讨论】：

那是我真正要去的方向。我有以下设置 1）测试环境（无压缩/缩小）2）认证（压缩/缩小选项但不是必需的）3）生产（需要压缩/缩小）
我同意，你应该可以随意切换。