为什么建议使用concat，然后在后者可以同时使用时使用uglify？ [英] Why is it recommended to use concat then uglify when the latter can do both?
问题描述
/ yeoman / grunt-usemin＃transformation-flowrel =noreferrer> here ，在Yeoman的咕tasks任务中。 $ b
默认情况下，流程是：concat - > uglifyjs。
考虑到UglifyJS可以同时进行连接和缩小，为什么需要两个在同一时间？
谢谢。
运行基本测试，以查看执行 concat 然后 uglify 与仅仅
package.json
{
name：grunt-concat-vs-uglify，
version：0.0.1，
description：一个基本测试，看看我们是否可以连接concat并只使用uglify ，
devDependencies：{
grunt：^ 0.4.5，
grunt-contrib-concat：^ 0.5.0，
grunt-contrib-uglify：^ 0.6.0，
load-grunt-tasks：^ 1.0.0，
time-grunt：^ 1.0 .0
}
Gruntfile.js
module.exports = function（grunt）{
//显示咕噜任务的执行时间
require（'time-grunt'）（grunt）;
//从package.json载入所有grunt- *包
require（'load-grunt-tasks'）（grunt）;
grunt.initConfig（{
paths：{
src：{
js：'src / ** / *。js'
}，
dest：{
js：'dist / main.js'，
jsMin：'dist / main.min.js'
}
}，
concat：{
js：{
options：{
separator：';'
}，
src：'<％= paths.src.js％> ;'，
dest：'<％= paths.dest.js％>'
}
}，
uglify：{
options：{
compress：true，
mangle：true，
sourceMap：true
}，
target：{
src：'<％= paths.src.js ％>'，
dest：'<％= paths.dest.jsMin％>'
}
}
}）;
grunt.registerTask（'default'，'concat vs. uglify'，函数（concat）{
// grunt默认值：true
if（concat）{
//将uglify dest更新为concat
的结果var dest = grunt.config（'concat.js.dest'）;
grunt.config（'uglify.target.src'，dest ）;
grunt.task.run（'concat'）;
}
// grunt default
grunt.task.run（'uglify '）;
}）;
};
在 src 中，一堆JS文件（包括未压缩的jQuery源文件）被多次复制，传播到子文件夹中。比普通的网站/应用程序通常要多得多。
结果表明，在这两种情况下，对所有这些文件进行连接和压缩所花费的时间基本相同。 br>
在 concat 上使用 sourceMap：true 选项时除外（请参阅下文）。
在我的电脑上：
grunt默认值：6.2s（只是uglify）
grunt默认值：true：6s（concat和uglify）
<值得注意的是，在这两种情况下产生的 main.min.js 是相同的。
另外， uglify 自动处理合并文件时使用正确的分隔符。
唯一的情况是，当添加 sourceMap：true 添加到 concat 选项。 main.js 旁边的 main.js.map 文件，结果为：
grunt默认值：6.2 s（只是uglify）
grunt默认值：true：13s（concat和uglify）
但是如果生产站点仅加载 min 版本，则此选项无用。
我发现主要的缺点在 uglify 之前使用 concat 。
当发生错误时其中一个JS文件 sourcemap 将链接到连接的 main.js 文件，而不是原始文件。而当 uglify 完成整个工作时，它将链接到原始文件。
更新：
我们可以为 uglify 添加两个选项，它们将链接 uglify sourcemap转换为 concat sourcemap，从而处理上面提到的缺点。 $ b
uglify：{
options：{
compress：true，
mangle：true，
sourceMap：true，
sourceMapIncludeSources：true，
sourceMapIn：'<％= paths.dest.js％> .map'，
}，
target：{
src：'<％= paths.src.js％>'，
dest：'<％= paths.dest.jsMin％>'
}
}
但看起来高度没有必要。
结论
我认为我们可以断定 concat 对于JS文件，如果我们使用 uglify ，并在需要时用于其他用途。
I keep seeing the recommendation for making JS files ready for production to be concat then uglify.
For example here, in on of Yeoman's grunt tasks.
By default the flow is: concat -> uglifyjs.
Considering UglifyJS can do both concatenation and minification, why would you ever need both at the same time?
Thanks.
Running a basic test to see if there is a performance difference between executing concat and then uglify vs. just uglify.
package.json
{
"name": "grunt-concat-vs-uglify",
"version": "0.0.1",
"description": "A basic test to see if we can ditch concat and use only uglify for JS files.",
"devDependencies": {
"grunt": "^0.4.5",
"grunt-contrib-concat": "^0.5.0",
"grunt-contrib-uglify": "^0.6.0",
"load-grunt-tasks": "^1.0.0",
"time-grunt": "^1.0.0"
}
}
Gruntfile.js
module.exports = function (grunt) {
// Display the elapsed execution time of grunt tasks
require('time-grunt')(grunt);
// Load all grunt-* packages from package.json
require('load-grunt-tasks')(grunt);
grunt.initConfig({
paths: {
src: {
js: 'src/**/*.js'
},
dest: {
js: 'dist/main.js',
jsMin: 'dist/main.min.js'
}
},
concat: {
js: {
options: {
separator: ';'
},
src: '<%= paths.src.js %>',
dest: '<%= paths.dest.js %>'
}
},
uglify: {
options: {
compress: true,
mangle: true,
sourceMap: true
},
target: {
src: '<%= paths.src.js %>',
dest: '<%= paths.dest.jsMin %>'
}
}
});
grunt.registerTask('default', 'concat vs. uglify', function (concat) {
// grunt default:true
if (concat) {
// Update the uglify dest to be the result of concat
var dest = grunt.config('concat.js.dest');
grunt.config('uglify.target.src', dest);
grunt.task.run('concat');
}
// grunt default
grunt.task.run('uglify');
});
};
In src, I've put a bunch of JS files, including the uncompressed source of jQuery, copied several times, spread around into subfolders. Much more than what a normal site/app usually has.
Turns out the time it takes to concat and compress all of these files is essentially the same in both scenarios.
Except when using the sourceMap: true option on concat as well (see below).
On my computer:
grunt default : 6.2s (just uglify)
grunt default:true : 6s (concat and uglify)
It's worth noting that the resulting main.min.js is the same in both cases.
Also, uglify automatically takes care of using the proper separator when combining the files.
The only case where it does matter is when adding sourceMap: true to the concat options.
This creates a main.js.map file next to main.js, and results in:
grunt default : 6.2s (just uglify)
grunt default:true : 13s (concat and uglify)
But if the production site loads only the min version, this option is useless.
I did found a major disadvantage with using concat before uglify.
When an error occurs in one of the JS files, the sourcemap will link to the concatenated main.js file and not the original file. Whereas when uglify does the whole work, it will link to the original file.
Update:
We can add 2 more options to uglify that will link the uglify sourcemap to concat sourcemap, thus handling the "disadvantage" I mentioned above.
uglify: {
options: {
compress: true,
mangle: true,
sourceMap: true,
sourceMapIncludeSources: true,
sourceMapIn: '<%= paths.dest.js %>.map',
},
target: {
src: '<%= paths.src.js %>',
dest: '<%= paths.dest.jsMin %>'
}
}
But it seems highly unnecessary.
Conclusion
I think it's safe to conclude that we can ditch concat for JS files if we're using uglify, and use it for other purposes, when needed.
这篇关于为什么建议使用concat，然后在后者可以同时使用时使用uglify？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
