Add ES6 Support

[SukkaW]

Close #70.
Another filter register is added in order to avoid require minifier every time the filter is executed, which might have less impact on performance.

[SukkaW]

I think we shouldn't use terser to completely replace uglify-js. I have noticed the different behaviors when I bring up test for the plugin.
Although terser has ecma: 5 as its default configuration, I still believe terser will compress the code into smaller es6 equivalent forms, which we should avoid.

[curbengh]

I have noticed the different behaviors when I bring up test for the plugin.

Example? Does the behavior break browser compatibility (i.e. IE)?

[SukkaW]

@curbengh

This is the result of uglify;

hexo-uglify/test/index.js

Line 35 in 6b39c7f

result.should.eql('var x={baz_:0,foo_:1,calc:function(){return this.foo_+this.baz_},bar_:2,baz_:3};console.log(x.calc());');

And this is the result of terser:

hexo-uglify/test/index.js

Line 64 in 6b39c7f

result.should.eql('var x={baz_:(0,3),foo_:1,calc:function(){return this.foo_+this.baz_},bar_:2};console.log(x.calc());');

// UglifyJS
var x={baz_:0,foo_:1,calc:function(){return this.foo_+this.baz_},bar_:2,baz_:3};console.log(x.calc());
// Terser
var x={baz_:(0,3),foo_:1,calc:function(){return this.foo_+this.baz_},bar_:2};console.log(x.calc());

Although it is pretty much equivalent, but it still raises a question if terser would have any other different behaviors.

[curbengh]

It looks like Terser compresses better, which is expected since it's more advanced than UglifyJS, so they would produce different output as a result.

I suggest to drop uglify in the next major (i.e. when dropping Node 8).

[curbengh]

doc

[curbengh]

when hardcoding the result, it could break in newer version of uglify/terser (just like hexojs/hexo#3829). I think comparing String.length should suffice.

[SukkaW]

If I just use:

const uglify = require('uglify-js');

// Just as an example. The usage of UglifyJS & Terser shouldn't be uglify(code).
uglifyFilter.apply(ctx, [code, { path: 'source/test.js' }]).should.eql(uglify(code));

Then the unit-test will become useless.

[curbengh]

what I mean is result.length.should.below(code.length).

[curbengh]

Even uglifyFilter.apply(ctx, [code, { path: 'source/test.js' }]).should.eql(uglify(code)); is useful

For example, try parsing config.uglify.priority without delete jsOptions.priority, the unit test would fail. In this case, the unit test correctly identify that the plugin wouldn't work if delete jsOptions.priority is missing.

---

Another example is parsing the options

uglifyFilter.apply(ctx, [code, { path: 'source/test.js' }]).should.eql(uglify(code, options));

in this case, the unit test can check whether the plugin parse custom options correctly.

[SukkaW]

what I mean is result.length.should.below(code.length).

That sounds as a good idea!

[SukkaW]

For example, try parsing config.uglify.priority without delete jsOptions.priority, the unit test would fail. In this case, the unit test correctly identify that the plugin wouldn't work if delete jsOptions.priority is missing.

If something like delete jsOptions.priority is missing, current unit test will not passed as well because when no valid configuration is passed to UglifyJS / Terser will resulted in undefined.

[curbengh]

Except for the documentation and unit test, I already tested locally, WFM.

[curbengh]

It's not fully compatible, e.g. Terser has Safari compatibility mode.