Uglifyjs: Harmony support

[osener]

I'm trying to use the excellent livenode with a project which uses ES6 features introduced in node v11, but unfortunately UglifyJS's parser chokes when it encounters a let statement or a generator function (function *() { yield true }).

[kevyworks]

Any comment on this?

[mgol]

That would be great to have, ES6 brings a lot of important new features but minification of all of them is still needed.

[Martii]

+1

[maranomynet]

+1

[darky]

:+1:

[ben-eb]

+1

[kevinjalbert]

:+1: just got bit by for...of.

[ghost]

If harmony support were enabled, we could also safely convert functions that don't use this to use the => syntax as well.

[fabiosantoscode]

+1 -- I'm writing a game for future browsers so I don't want to add the overhead of traceur to my code.

I also think converting functions to arrows when this is not used would be pretty nice.

[fabiosantoscode]

Adding harmony support on my fork, https://github.com/fabiosantoscode/UglifyJS2/tree/harmony little by little, to later pull request that back to this project.

Got arrow functions working so far (I think).

[rvanvelzen]

@fabiosantoscode Awesome! It would be super cool if you could submit separate new language features as separate pull requests. That will make reviewing them a lot easier. :)

[fabiosantoscode]

Okay, I'll restructure my commit history to do just that.

I'm writing some tests for the parser, and am thinking of doing so for the output as well, is that okay?

[rvanvelzen]

That is certainly okay! Related tasks: #337, #410.

[19h]

:+1: bump.

[simonzack]

:+1:

[RamIdeas]

:+1:

[lewispham]

:+1:

[avdg]

I hope everyone knows how to find technical information about ecmascript 6 / ecmascript 2015

Some examples:

• Candidate specs: http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
• Es discuss: https://esdiscuss.org/

Note: understanding the structure of the spec, instead of reading it may be more important long term, so its easy to find information about specific items of the spec.

Good luck

[niemyjski]

+1

[f0rmat1k]

:+1:

[RevanProdigalKnight]

:+1:

[dgieselaar]

Please, everyone, don't comment with a 👍 or a +1: they add nothing to the discussion and will only antagonize people who have expressed their interest The Right Way™: with the subscribe button.

[darky]

Like most clearly expressed priority of issue
You can even sort by "Most commented"

[Martii]

@plestik
Adding a vote for support is always in the best interest of a project and is how it has been done for decades. ES6 syntax is something that this project should support to maintain high standards of quality. I am also subscribed to this thread. As you can see by the community outreach there is a strong interest and it should be taken seriously not complained about. :)

[avdg]

Maybe we should start with this question as we can all learn things from each other:

What is your favorite es6 feature?

[avdg]

Those who want to experiment with es6 can do it here: https://iojs.org/en/es6.html

It's basically a fork of node with many es6 features enabled by default.

[Martii]

What is your favorite es6 feature?

Block level scoping with let statement versus var is a plus. This is the most common entry syntax for ES6.

[RevanProdigalKnight]

I have to agree with @Martii; let will be a huge plus for temporary loop variables.

[art-in]

What is your favorite es6 feature?

generators ftw!
co + generators + promises ♡

[darky]

@artin-phares Awesome!

[avetisk]

:+1:

[albertorestifo]

:+1:

[arackaf]

I'm curious if there's some sort of status page tracking which ES6 features are yet implemented. Like this, over at Esprima.

https://github.com/jquery/esprima/issues/1099

[sbrl]

That would be handy not only for the UglifyJS developers, but also for
other developers who use this library to minify their code.

On 13/07/2015 02:33am, arackaf wrote:

I'm curious if there's some sort of status page tracking which ES6
features are yet implemented. Like this, over at Esprima.

jquery/esprima#1099 https://github.com/jquery/esprima/issues/1099

—
Reply to this email directly or view it on GitHub
https://github.com/mishoo/UglifyJS2/issues/448#issuecomment-120780583.

[rbozan]

+1.. At least add the let and const tags as they should act the same as "var", and in the future you could make the let tag name change on every block

[Martii]

Note ECMAScript 6th Edition _(ES6 a.k.a Harmony)_ was finalized relatively recently last month.

See also:

• http://ecma-international.org/ecma-262/6.0/

[SET001]

What is your favorite es6 feature?

Please add support for classes and let!

[rbozan]

By the way for anybody reading this, just use Babel.io before you use Uglify, it would work

[mgol]

use Babel.io before you use Uglify, it would work

This prevents browsers from using their own optimized ES6 implementations; over time it will get faster than transpiled ES5 output. Also, this forces even good, modern browsers to download a lot of polyfills.

ES6 support in a JavaScript minifier is needed. It will get more & more needed in the future.

[probins]

also, some ES6 code, like arrow functions, is more concise than ES5, so a modern minifier should be converting ES5 to ES6 for optimal compression

[fabiosantoscode]

@probins I started work on that, but it currently depends on my pull request for arrow functions being accepted.

[rvanvelzen]

I started work on that, but it currently depends on my pull request for arrow functions being accepted.

Could you point me to that PR? I can't seem to find it?

[fabiosantoscode]

I didn't create it yet after all, it was dependent on whether my other pull request was accepted. I'll send it soon

[rbozan]

@mzgol Atleast it works for now, I don't really see this feature getting added to Uglify soon

[g-ortuno]

@rvanvelzen when is the next release planned? Can't wait to use arrow functions with uglify :smile:

[fabiosantoscode]

It would be great to see "beta" support of ES6 coming out so people can report any issues in our implementation of it before we finish all the features.

[g-ortuno]

@fabiosantoscode +1

[84564221]

See UglifyJS2/tree/harmony

[lewispham]

@fabiosantoscode Do you have any list of anticipated features?

[sbrl]

@fabiosantoscode Beta releases sound good. I think that the github release system lets you mark a release as a pre-release - perhaps that would work?

[fabiosantoscode]

@sbrl my idea was more like, release uglify-js as it is, but with the ES6 it currently supports.

@tresdin Destructuring is done, but it doesn't work with --mangle-props yet. I am currently working on ES6 strings (the ones with backticks), and plan to work on class, let, and computed properties ({["fo" + "o"]: "bar"}) next, but don't know which one I'll do first yet.

[lewispham]

Thanks for your contribution @fabiosantoscode . AFAIK, these ES6 features may affect UglifyJS results.

• for...of
• Arrow functions
• class
• let
• const
• Template strings
• Destructuring assignment
• Object initializer (shorthand property names, computed property names, shorthand method names)
• Default parameters
• Rest parameters
• Spread operator
• Generator function
• Binary and octal numeric literals
• import
• export

I think it would be nice to have for...of, arrow functions, class, let, const, destructing assignment, template strings, and Object initializer features in _beta_ version since most of them are now supported in major browsers.

[fabiosantoscode]

Of those features you listed, these are the ones not done yet:

let
Template strings
Object initializer (computed property names, shorthand method names) (shorthand props are done)
Default parameters
Generator function
import
export

Const has been ready for quite some time.

[g-ortuno]

@fabiosantoscode my vote is for class and let!

[Martii]

for (object of objects) e.g. the of

[fabiosantoscode]

@Martii got that working in the harmony branch

[Martii]

@fabiosantoscode
Awesome... just hope _node_ at some point gets full ES6 support _(w/o a build switch)_ so I can start using that rather than just uglify'ing it for serving.

[fabiosantoscode]

@askmatey if I recall correctly, you can use #harmony instead of a commit hash

@Martii Indeed, using traceur is a bother and has quite a performance toll.

[niloy]

+1 👍

[callaars]

+1

[wilk]

+1

[terinjokes]

@askmatey Modifying gulp-uglify's package.json is unnecessary, you can provide your own version of UglifyJS by importing gulp-uglify/minifier instead:

var gulpUglify = require('gulp-uglify/minifier');
var uglifyJS = require('uglify-js');

gulp.src(['*.js'])
  .pipe(gulpUglify({}, uglifyJS)  /* opts, UglifyJS */
  .pipe(gulp.dest('dist/'));

[weekens]

+1

[cin210]

+1

[fabiosantoscode]

Chill, everyone. This is being worked on

[zhiqingchen]

good news

[avdg]

If someone like to experiment on harmony uglify in experimental usage, maybe this could help https://stackoverflow.com/questions/16350673/depend-on-a-branch-or-tag-using-a-git-url-in-a-package-json.

Note: experimental usage only, things may break!

[Marqin]

@fabiosantoscode
On your "not working" list there is no Spread Operator, but it's not working for me:
Unexpected token: punc (.) [./app/index.js:22,0]
on uglify-js 2.6.1.

[fabiosantoscode]

@Marqin you need to grab the uglifyjs code in the harmony branch, not from npm. The new stuff hasn't been merged in yet but you are welcome to try it, and more than welcome to give any feedback or bugs you might find ;)

[Sasstraliss]

How do we use the new code to support ES6? I'm not familiar with the procedure to overwrite the uglifyjs I'm using via NPM.

[avdg]

@Sasstraliss Watch a few comments above (https://github.com/mishoo/UglifyJS2/issues/448#issuecomment-163775898)

[Martii]

@avdg
After the holiday _(this includes new years)_ I'll see about opening a test route on OUJS that will give some more testing data... I'll need to trap any errors _(hopefully)_ that pop up because I don't want to trip our production into a restart.

[fabiosantoscode]

@Martii awesome! I haven't worked much on that branch the past months, but besides the open pull request for defaults, there's generators and little more left.

I have used some of the new features in my MP project, it's a (terrible) game written in es6 which doesn't use a es6-es5 compiler if it detects the browser supports some es6. It minifies the es6 with uglifyjs if these features are supported.

[Martii]

@fabiosantoscode
We're currently running on [email protected] so it shouldn't be too difficult but if _node_ updates to [email protected] , and we do that before the route, I'm not sure how _express-minify_ will handle this in the "flat, flat, flatter" dep tree that 3.x gives of _npm_ ... with having one dependency in the package.json asking for one version of UglifyJS2 and our depth 0 request from GH... time will tell when I get back to main dev station after the holidaze.

[vpj]

+1

What is your favorite es6 feature?

Generators!

[RevanProdigalKnight]

Could we please get an updated list of what's still left before the harmony branch is ready?

[tenKinetic]

Nice work people (mostly @fabiosantoscode?). Finally had an afternoon to sit down and see if I can get the harmony branch to provide me with some uglified ES6 classes rather than ES5+polyfill. Took 20 mins because of the time and effort you guys have put in. Thanks.

[buunguyen]

If Uglifier supports generators, we can use it to process transpiled code because generators can't be transpiled. Usage of other ES6 features can at least be handled by Babel. IMO, support for generators should have high priority.

[mgol]

@buunguyen What do you mean by "generators can't be transpiled"? They sure can.

[buunguyen]

Sorry, you're totally right. I've always thought Babel can't transpile generators, turn out it's a configuration problem. Thanks for clearing my head.

[fabiosantoscode]

Generators have been addressed in a pull request a while ago, but it seems like it's been abandoned.

All that's missing besides generators, if I recall correctly, is some parts of restructuring objects and arguments, specifically constructs like var { a:b=3 } = foo;.

I don't think I wish to implement the import statement until the spec on how they actually work is completed

[RevanProdigalKnight]

@fabiosantoscode According to MDN the spec is completed, but no browsers or runtimes have implemented it yet - just transpilers (Traceur, Babel, etc.). It doesn't look like there's really anything that can be minified in an import statement aside from getting rid of spaces around commas and curly braces. The export statement looks to be pretty similar.

[RamIdeas]

It doesn't look like there's really anything that can be minified in an import statement...

@RevanProdigalKnight Err... variable names?

[sbrl]

@RevanProdigalKnight @fabiosantoscode There's active development going on in the v8 engine on destructuring: https://bugs.chromium.org/p/v8/issues/detail?id=811

[topaxi]

@RevanProdigalKnight imports could be renamed to minify the output:

import foo, { bar, baz } from "foo"

can be minified to:

import f,{bar as b,baz as c}from"foo";

or

import { default as bar } from "bar"

to:

import b from"bar";

[RevanProdigalKnight]

@RamIdeas, @topaxi Unless I'm mistaken, the only names that would be minifiable would be the aliases (name as alias) in the import statement, which technically speaking, is an as statement inside the import statement, and could probably be adapted from the existing var, let, or const code with some modifications.

I'm also guessing the actual module names in the import/export would probably have to be left alone so as to avoid cross-file collisions or other problems when you aren't the owner/creator of the other file (e.g. external libraries).

e.g. import reallylongmodulename as alias from "module" -> import reallylongmodulename as a from "module"

[topaxi]

You can't alias the default import, it's already an alias:

import foo from 'foo'

Is the short form of:

import { default as foo } from 'foo'

[Martii]

@fabiosantoscode
Does the Harmony branch actually obfuscate ES6 code?

I just did one single test on my eldest and most known user.js and the code itself doesn't seem to resemble the native/raw code I put in... unfortunately I can't test it since USO went offline but perhaps the mirror I can get it working on even though parts of the mirror are missing.

---

P.S. strict ES5 appears to obfuscate too with identifier changes... didn't notice this with ES5 before... so n/m on the question. Sorry to bother.

Other than this surprise... seems to be working with my legacy Moz ES6 code so far with the server. :)

[Martii]

This is a little off-topic... but we've just gotten one report of ES5 alleged failure... I can't see anything unique pattern wise in that users most installed user script but I'm not the UglifyJS2 expert here. _express-minify_ is pulling current release 2.6.1 and within the next few days or earlier I'll be _(hopefully)_ switching to the harmony branch specific to this issue... which should be the same for ES5 based code I think.

Obviously that report is super vague and I don't doubt there will be some out there that won't want to do minification _which is why they have a choice on our site_ instead of imposed like some... but as I mentioned in our issue ticket we've been minifying all node .js since _express-minify_ came into being in our project so imho that invalidates a bit with lack of citation from that author.

[avdg]

@martii Please open a new issue in case you manage to isolate the bug somewhat in such a way others can repeat (a script that fails compiling, a test case that shows the code isn't doing the same after minimizing, etc...).

Also note that I'm currently running test262 es5 tests (yeah, these are the standard es tests) and I've managed already to track quite many bugs and squash a few of them (with some help from others).

Test262 es6 tests is scheduled on my part to be done later when I have the time to do this (though I don't have a date on when I do this). Though I can already guess that arrow functions are likely not to behave properly on a subject like scoping (though such cases only proof that testing is urgently needed).

For those who want to know: I'm using the tester from https://github.com/mishoo/UglifyJS2/pull/821

[fabiosantoscode]

From the many projects I've used uglifyjs in, even with the unsafe option I
never experienced any bug either during compilation or in the resulting
code. This is super solid software.

I can't say the same for my branch yet, since it hasn't been battle tested.
I just used it for one project, and used very little ES6.

About import, I'd say this can be released. I have a feeling that browsers
will never implement, and if they do, we can always implement it ourselves
then! It is in the interest in keeping uglifyjs simple and practical, as
opposed to being complete, even more so than the browsers we're supposed to
be targeting.

On 09:38, Tue, 19 Jan 2016 Marti Martz [email protected] wrote:

This is a little off-topic... but we've just gotten one report
https://openuserjs.org/discuss/How_to_disable_install_with_minification_on_my_script
of ES5 alleged failure... I can't see anything unique pattern wise in that
users most installed script but I'm not the UglifyJS2 expert here.
_express-minify_ is pulling current release 2.6.1 and within the next few
days or earlier I'll be switching to the harmony branch specific to this
issue... which should be the same for ES5 based code I think.

Obviously that report is _super vague_ and I don't doubt there will be
some out there that won't want to do minification _which is why they have
a choice on our site_ instead of imposed like some... but as I mentioned
in our issue ticket we've been minifying all node .js since
_express-minify_ came into being in our project so imho that invalidates
a bit with lack of citation from that author.

—
Reply to this email directly or view it on GitHub
https://github.com/mishoo/UglifyJS2/issues/448#issuecomment-172792982.

[Martii]

@fabiosantoscode

Well it's not just about browsers implementing it... _node_ packages can include ES6 in it too... so I get double-duty testing here... this is why I wanted some ES5 data in first which of course I'll report what I can as mentioned by @avdg in new issues... but not everyone in the user script community is vocal... so sometimes a small few get to guess and/or figure it out. I have seen some .user.js in the past that had import statements... had no clue on how it was used at the time when it was new _(some time back in the last 10 years)_... but I do see it in use now on some websites... and it will probably be in _node_ based packages sooner than later.

[lewispham]

How can I report an issue that's related to harmony branch?

[avdg]

You can open an issue and mention its harmony related. Note that all work is done in public and probably all work done here is voluntarily with limited resources (it consumes time from humans) and that the code is public (so anyone feeling to submit fixes can submit them if they know the code and how to use github).

Reported harmony issues may be labeled with the harmony labels later on with those having the authorization to do that.

[mishoo]

@tresdin I added a harmony label, just use it when creating an issue. As a personal preference, I'd also prepend [ES6] to the subject; I know that's redundant with the label, but it helps when I see a list of issues in my mailbox.

I welcome more people to test this branch and report bugs/send fixes. However I'm not (yet?) writing ES6 myself, nor do I have any need to minify it. I switched to harmony branch once and accidentally found some bugs (didn't care to investigate, but they seemed related to keeping the correct start / end offsets in the AST nodes). So I second @fabiosantoscode here—I do worry about stability and prefer not to merge this branch until proven solid.

[Martii]

@mishoo

Understanding that the branch is considered unstable... comments like these have me a bit concerned for testing... if the ES6 branch hoses one of our node package .js files that wouldn't be good for production... so far I don't see any issues with our packages but I periodically do dep updates and I can test general usage but I'd have to back out to the ES5 release branch if there is a problem. One of my points on dev OUJS is to do a test route but I don't know if _UglifyJS2_ can be done with a new statement or not so I can isolate the instance... typically in _node_ it's just require('something') which is a static object I think... so I have a conundrum here. _(with express-minify in the mix too ... please note sometimes I miss the obvious as my mind is multi-tasking elsewhere too)_

[fabiosantoscode]

Have 2 uglifyjs!

"uglifyjs": " whatever.version.lol",
"uglifyjsintheharmonybranch": "git repo"

(Haven't tested it. Does it work?)

On 16:43, Thu, 21 Jan 2016 Marti Martz [email protected] wrote:

@mishoo https://github.com/mishoo

Understanding that branch is considered unstable... comments like these
have me a bit concerned for testing... if ES6 hoses one of our node package
.js files the harmony branch that wouldn't be good for production... so far
I don't see any issues with our packages but I periodically do dep updates
and I can test general usage but I'd have to back out to the ES5 release
branch. One of my points on dev OUJS is to do a test route but I don't know
if UglifyJS2 can be done with a new statement or not so I can isolate the
instance... typically in _node_ it's just require('something') which is a
static object I think... so I have a conundrum here.

—
Reply to this email directly or view it on GitHub
https://github.com/mishoo/UglifyJS2/issues/448#issuecomment-173629539.

[mishoo]

@fabiosantoscode — Of course it works. It's called a fork. ;-) I have nothing against forks—do it, advertise it, have people using it and make it stable, and later we can merge back. At worst we end up with two divergent versions, but this seems unlikely.

[fabiosantoscode]

It's not a fork, it's me trying to get npm to download 2 uglifyjs modules under different names. There can be only one node_modules/uglifyjs

[Martii]

@fabiosantoscode

There can be only one node_modules/uglifyjs

That's definitely one of the issues with [email protected] ... we are currently on [email protected] which might allow it since the deps are not "flat, flatter..." as paraphrased from _npm_. As I'm watching and interacting with _node_ right now with their tests and [email protected] it could come any day now... this presents a short term interruption issue... so I would have to find a solution that will do it both ways.

I'm not "as worried" with packages .js because I can usually catch those... but it does take longer to do the full battery of tests I do for the site every dep update which slows our development. I debug packages too... and if it's a ES6 glitch that shows up that's when I get to toggle it to the ES5 release branch and wait and see if it happens there _(blech)_. We do have two clones on the VPS so I can toggle between them... but that requires human interaction... hopefully I would be conscious to observe potential issues.

I'll probably just take a leap of faith and any consequences will rest on my shoulders... but I don't want to upset our users... an occasional inconvenience is okay but if it's too long then they get restless.

Another option might be, which is lengthy, is to only UglifyJS2 the scripts and go serve the static packages .min.js _(if available)_ with _express-minify_ and tell it to ignore everything else but the user scripts... but I'd still like to have my cake and eat it. ;) :)

[mgol]

There can be only one node_modules/uglifyjs

That's definitely one of the issues with [email protected]

npm 3 only flattens what can be flattened, if you have two packages in dependencies that depend on conflicting versions of a specific package, this package won't get flattened. npm@3 separates the logical dependency tree from the physical one - the directory structure. The logical tree is the same as the directory tree in npm@2 but it shouldn't matter that it's no longer the case in npm@3.

[RevanProdigalKnight]

I've been using npm 3.x for a while now for my own projects and I haven't run into any dependency issues.

[Martii]

Yah looks like [email protected] has one folder too for uglyfy-js when I include it manually as a depth 0 dep and _express-minify_ requests release... the physical folder is the harmony branch and no _uglifyjs2_ _(uglify-js folder)_ in the _express-minify_ folder.

@fabiosantoscode or anyone...
So do you think a name change would help? say "uglify-js-harmony" ? This is purely git retrieval so that is all release would need to observe I think.

[Martii]

@fabiosantoscode
Noise time... sorry in advance... that gives me two physical folders with [email protected] ... one at depth 0 and one under _express-minify_ ... logical _(in memory)_ testing next with instance provided by _express-minify_ package.

[lewispham]

@mishoo Adding lables is only available to contributors. Am I missing something?

[klimashkin]

Hi! Are there any concrete plans about release date? Or maybe month?
Chrome 49 already 92%ES6, ff45 - 85%
Our project already have build for modern browsers with less babel transformations, but, unfortunately we cant uglify it. (https://github.com/mishoo/UglifyJS2/issues/448#issuecomment-150728325 doesn't help)

[kzc]

@fabiosantoscode > It's not a fork, it's me trying to get npm to download 2 uglifyjs modules under different names. There can be only one node_modules/uglifyjs

It may be easier for you and potential npm users if the harmony branch was forked with a new module name. May I suggest fabiosify?

[klimashkin]

Maybe simple UglifyJS3-alpha1..n :)

On Thursday, January 21, 2016, kzc [email protected] wrote:

@fabiosantoscode https://github.com/fabiosantoscode > It's not a fork,
it's me trying to get npm to download 2 uglifyjs modules under different
names. There can be only one node_modules/uglifyjs

It may be easier for you and potential npm users if the harmony branch was
forked with a new module name. May I suggest fabiosify?

—
Reply to this email directly or view it on GitHub
https://github.com/mishoo/UglifyJS2/issues/448#issuecomment-173818167.

_Sincerely yours, Paul Klimashkin._

[avdg]

We don't have anything stable for release yet. While for example v8 (chrome's js engine) had lots of things behind flags for a long time we had yet to create a harmony branch.

Now we do have one we rely on implementors and testers and because es6 is larger than just a few features this may take some time.

But note that PR's are merged pretty quickly and thus implementation are currently the things that block progress for now (well they take some time anyway).

[kzc]

Timely merges aren't really the issue. It's the fact that there's no distinct npm module name and CLI script name for uglifyjs-es6. This limits its use and testing in the wild.

[avdg]

Yeah, an external package would be nice and wouldn't conflict with the current package.

[StephanBijzitter]

Any updates on this? I just bumped into #938

[julmot]

Just got this error when having an arrow function:

Running "uglify:dist" (uglify) task
JS_Parse_Error {
  message: 'Unexpected token: operator (>)',

so it seems to have no update

[sbrl]

@julmot I think you need to use the special harmony branch of UglifyJS2,

[c-f-h]

I'll second that it would be great to have a separate experimental package published on npm with ES6 support.

[PokemonAshLovesMyTurkeyAndILikeYouTwo]

Do you guys know if it's possible to edit one of the files here:

uglify-js\lib

and make it so the uglifying process basically skips template strings?

See my issue, I know ES6 support isn't ready, but I'm only using template strings and just need to find a way to skip that process if possible

Edit: it looks like the error is coming from

function parse($TEXT, options) {

inside the parser.js file

If anyone can try to get a temporary fix so it can skip the template strings that would be great. If I find a fix first, I'll post as well

[PokemonAshLovesMyTurkeyAndILikeYouTwo]

Great News! Template Strings are now working!

WARNING: This is extremely hacky and only use if you are not using tilde keys INSIDE template strings.

Follow these simple steps:

Step 1

Replace the read_string function at /lib/parse.js with:

    var read_string = with_eof_error("Unterminated string constant", function(quote_char){
        var quote = next(), ret = "";   
        for (;;) {
            var ch = next(true, true);
            if (ch == "\\") {
                // read OctalEscapeSequence (XXX: deprecated if "strict mode")
                // https://github.com/mishoo/UglifyJS/issues/178
                var octal_len = 0, first = null;
                ch = read_while(function(ch){
                    if (ch >= "0" && ch <= "7") {
                        if (!first) {
                            first = ch;
                            return ++octal_len;
                        }
                        else if (first <= "3" && octal_len <= 2) return ++octal_len;
                        else if (first >= "4" && octal_len <= 1) return ++octal_len;
                    }
                    return false;
                });
                if (octal_len > 0) ch = String.fromCharCode(parseInt(ch, 8));
                else ch = read_escaped_char(true);
            }
            else if (ch == quote) break;
            ret += ch;
        }

        if(quote_char.match(/`/)){
              var tok = token("string", ret);
              tok.quote='MAKETEMPLATESTRINGSGREATAGAIN';
              tok.value = tok.value.replace(/\s/g, "") // Remove the extra spaces leftover from our hack
        }else{
        var tok = token("string", ret);
        tok.quote = quote_char;
        }
        return tok;
    });

Step 2

Replace the switch statement inside function next_token in /lib/parse.js to:

        switch (code) {
          case 34: case 39: return read_string(ch);
          case 96: return read_string(ch); // Handle Template Strings
          case 46: return handle_dot();
          case 47: return handle_slash();
        }

Since tilde key has a keyCode of 96

Step 3

Now in /lib/output.js replace the function quote_single() with:

        function quote_single(ev) {
                if(ev == 'MAKETEMPLATESTRINGSGREATAGAIN'){
                        return "`" + str.replace(/\n/g, "\\'") + "`";
                }else{
                        return "'" + str.replace(/\x27/g, "\\'") + "'";
                }
        }

And.. right below that, there is a switch statement, replace that to:

        switch (options.quote_style) {
          case 1:
            return quote_single();
          case 2:
            return quote_double();
          case 3:
            return quote == "'" ? quote_single() : quote_double();
          default:
            return dq > sq ? quote_single(quote) : quote_double();
        }

(we are now passing the quote property we assigned earlier so we can check if TEMPLATESTRINGSAREGREATAGAIN inside the quote_single function above.

Boom. Done.

Proof:

Before:

After:

Have a wonderful day everyone, enjoy!

[rvanvelzen]

Great News! Template Strings are now working!

They've been working for ages in the harmony branch. Please don't misinform other people by posting junk fixes.

[PokemonAshLovesMyTurkeyAndILikeYouTwo]

They've been working for ages in the harmony branch. Please don't misinform other people by posting junk fixes.

Last time I checked 'working on' doesn't mean it's accessible. My fix works fine for me, especially since I'm ONLY using template strings and need my game to be compiled now. I don't got time to wait for ages, nor hear negative & condescending things from unappreciated people like yourself.

[rr-]

Or you can just target harmony branch in your package.json like this and not have to maintain some weird local fixes.

[mgol]

@PokemonAshLovesMyTurkeyAndILikeYouTwo Your hack is incorrect, you can't just remove white spaces from inside template strings, this changes what the code does.

[PokemonAshLovesMyTurkeyAndILikeYouTwo]

@mgol

Hack may be 'incorrect', but I have already compiled tons of scripts using it with no issues.

@rr- That's a good idea and way better than my solution. Thank you for that. I didn't know you could use harmony / git like that. I wish I knew, I would of just did that.

[mgol]

You may have as well compiled tons of scripts where you replace all occurrences of the string 'all' with 'none' but if it worked for you this still wouldn't prove this patch is right.

[avdg]

I'm currently running some test262 tests on harmony to see how far we are progressed by now. There are quite some errors and the logs are huge (while the test is still running) but I hope to extract some useful information from it.

There's been a lot of work done on the harmony branch, and we might want to thank those who contributed to or made it possible to get the code base we have today.

[fabiosantoscode]

I was looking at the failures, and it seems a bit weird that things like Promise fail. Promise is not a syntax feature, it's a standard library addition, so I wouldn't expect any failures in uglifyjs.

[avdg]

Promise errors aren't caused by UglifyJS, they are caused by node because the tests still have to be executed. I'm still working to get better information in the markup files to clarify that and will update the gist partially later. All that stuff is still in development.

Tests definitely caused by UglifyJS will get a rubberstamp telling that the error is caused by UglifyJS soon. For now, only the directories are listing how many errors are caused by UglifyJS.

Running the test262 suite takes almost 3 hours on my computer, converting these logs to markup format takes less than a second, but the program will be adjusted to the needs.

[avdg]

I've updated the gist with fixes I've already made.

[avdg]

Updated the gist even more now, some tests have their cause determined. Note that the results did ran on node 6.0.0 without the harmony flag. I should have done it with the flag on.

[avdg]

Uh wrong setup :-) I wanted to post some gist results but they were invalid.

[Martii]

@avdg
Hehe... one of those days/weeks. ;) I appreciate your testing... steers me in some alternate directions/thoughts too. Keep up the great work... this applies to everyone too. :)

[avdg]

Yeap, tests are fixed for now :-)

https://gist.github.com/avdg/85ddc1e7ed2c6f32987446620fa958f2 - running on node with harmony flag

https://gist.github.com/avdg/43002267f959210a69aa3ec0f21ed751 - running on node with harmony flag

[willin]

es7 async

[avdg]

Added more types of errors including parse errors to the results overview. Pretty sure they are useful.

[KingScooty]

Potentially daft question, but i'm just trying to get up to speed with this thread. How do i get Webpack 2 using this Uglify harmony branch?

[christophehurpeau]

@KingScooty just add this as a dependency: "uglify-js": "github:mishoo/UglifyJS2#harmony"

[KingScooty]

@christophehurpeau Nice! Will webpack automatically pick that up from the package json?

[juodumas]

Oops, didn't know this was already answered (e-mails seem to be delayed). @KingScooty: just do this and see for yourself:
$ npm i github:mishoo/UglifyJS2#harmony --save-dev
$ webpack -p

[KingScooty]

Just works too! Thought there'd be more to it than that! Love it! Cheers guys!

[iceprosurface]

so arrow function syntax still cannot be used? if could ，i vote to '=>'.

[kevincox]

Yeah. I'm not going to like the only reason I am transpiling one project to es5 is so that I can minify it with uglify. It would be really nice to get basic es6 support working.

[fabiosantoscode]

Arrow functions and a lot of other es6 features are supported by the harmony branch. To install, use

npm i mishoo/UglifyJS2#harmony

[avdg]

test262 results are just an indication. The tests itself may be over the top and uglify may ship with failures on test262 depending on the context of these errors (tests are just designed to fail despite the lack of real usage in the real world).

[avdg]

Also I like to note that the test262 suite is in active development. So it might be possible that we might fail more and still have improved on it. Also there are small features expected to be added in ecmascript 2016, but they are very small (** / **= operator and Array.prototype.includes).

[jprichardson]

@kevincox check out Google Closure Compiler. It officially supports es6 since October 2015 and compress js better. The only cons is it requires java.

@egoroof it's my understanding that it doesn't output ES6 though. That's a problem, especially if you want to use native generator support. So by that metric, Uglify supports ES6 as well since you can preprocess with Babel. Please correct me if I'm wrong.

[klimashkin]

@egoroof Google Closure Compiler doesn't compress ES6. First it transforms it to ES5 with traceur-compiler and then compress as usual.
Try it https://closure-compiler.appspot.com/home#code%3Dfunction*%2520rr%2520()%2520%257B%250A%2520%2520const%2520r%2520%253D%2520yield%2520nn()%253B%250A%257D%250A

[egoroof]

@jprichardson and @klimashkin yes, you are correct. Sorry for misleading.

[avdg]

ES 2017 / ES 7 is out now, and since it's easy to implement the **= and ** operators, I'm doing them now. This while chrome doesn't seem to support ** operators yet.
The other important change is Array.prototype.includes, but support for that will automatically be included in uglifyjs once it is supported the execution host (which is mostly node, unless ported to the browser).

On the background I am trying to document on everything related to ([{ ... some content that may be , separated... }]) because that seems to be complex and easy to add duplicated code.

Maybe I have to take a look at computed properties as well as they don't seem to behave good enough in the test262 tests.

Support for spread in array literals is already implemented in #1125 but is still not merged yet.

[arackaf]

Am I seeing correctly that basic array destructuring [edit - I meant to say array spread] doesn't work? I've installed from the harmony branch, and most ES6 features are working ... strange that that one wouldn't be. Am I missing something?

[avdg]

Depends on what you call array destructuring. It could be an assignmentPattern (those in front of = or in call expression), literal (after =) or in parameters.

And there are many pr in queue if you like to test them.

[arackaf]

Sorry! Not destructuring! Array spread. I meant to say array spread above.

Basically this.

let arr = [1, 2, 3];
let arr2 = [...arr];

[avdg]

See #1125

[klimashkin]

@arackaf It's a spread, not destructuring

[arackaf]

@klimashkin - yep, already corrected, thanks.

@avdg good to know - thank you for the info.

[graingert]

@mishoo is there a list of which harmony features are supported? Do we know what transpilation rules are needed to support all of ES6 with minimal transpilation.

[graingert]

ah I found one here: https://github.com/christophehurpeau/babel-preset-modern-browsers/blob/master/webpack2-uglifyjs.js Looks like it's mostly done! Neat.

[acarstoiu]

Is there any hope that the harmony branch gets merged into the main stream? I believe everyone here would be satisfied with just a subset of ES6 features, including just the one or two reasons they came to this issue in the first place.

A release with partial ES6 support would be great. Using a development branch in production (because that's the only environment where _UglifyJS_ is truely useful) is too much gambling.

[graingert]

Eslint seems to be entirely supported. (Except for one outstanding bug).
Let's wait for that bug to be closed then release?

At least create a package with a different name uglifyjs2-harmony or
uglifyES
On 22 Jun 2016 3:23 pm, "acarstoiu" [email protected] wrote:

Is there any hope that the harmony branch gets merged into the main
stream? I believe everyone here would be satisfied with just a subset of
ES6 features, including just the one or two reasons they came to this issue
in the first place.

_A release with partial ES6 support would be great._ Using a development
branch in production (because that's the only environment where _UglifyJS_
is truely useful) is too much gambling.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mishoo/UglifyJS2/issues/448#issuecomment-227759909,
or mute the thread
https://github.com/notifications/unsubscribe/AAZQTKyP_UdM3ol_N16ja96kNc9CAuBLks5qOUVIgaJpZM4BpCcE
.

[moroine]

I totally agree with @acarstoiu

At this time, I'm a little bit frustrated to not be able to use ES6 features in Production environment. I think working in incremental step would be nice. What I see is to associate a babel preset to transpile every unsupported ES6 features.

[arackaf]

I would argue in favor of waiting until every ES6 feature is complete. Saying "Uglify doesn't support ES6 yet, so just keep transpiling" will be a lot easier to deal with than "These N ES6 features are not done, so only use UglifyJS on your ES6 if you never use any of them."

[acarstoiu]

@arackaf Transpiling is stupidly useless. The interpreter will see only ES5 code which means it will not apply any enhancements or optimizations specified in ES6. Not to mention that any generated code is most probably suboptimal.

Sorry for the bluntness, but only what happens in production really matters.

[kzc]

Native ES6 speed is not as rosy as you may think. JS engines have had years of tuning for ES5.

https://kpdecker.github.io/six-speed/

[avdg]

Actually a programming language may add more sugar to its language. Although most sugar are carefully balanced, they tend to make the language slower at cost of easier to write code.

This doesn't have to be that dramatic though, cpu's are currently only improving and becoming faster and faster and some features may allow more access to specific specialized hardware. At least if an interpreter decides to use it too.

[acarstoiu]

I don't intend to turn this into a discussion, but I expect a slight peformance gain (all other conditions being equal) between explicit class-like constructs (ES5) and the _class_ statement in ES6, simply because the interpreter is parsing less code and can make more decisions, knowing about the intended outcome.
And that's just an example.

Also no matter how the hardware is evolving, people that make it insufficient will always exist :wink:

[avdg]

Not if we all know where the trade-offs are. Anyway, there is always work if someone is digging deeper in stuff that can be better. Being paid for it is a bit different ;-)

Edit: Meh, I'm getting too generic with wording that it doesn't bound into a single context anymore

[arackaf]

@acarstoiu ummm, if your app is _that_ performance sensitive I'm really not sure why you're transpiling at all. Why are you not hand-writing every line of JS your users will execute?!

And yeah, @kzc beat me to it. Engines have not had much time to optimize ES6 (yet). There's no reason to assume un-transpiled ES6 will necessarily be faster on all engines.

I'm eagerly looking forward to UglifyJS being ES6 compat. My only argument was that shipping the harmony branch without full support would be bad, and dangerous for people using it.

[avdg]

We're again at a point that there are lots pr, I guess the activity the last weeks is very high. But we're too much dependent on the bus factor I guess to make this project really work.

[arackaf]

@avdg - are you saying UglifyJS2 isn't working as a project anymore? I hope I misunderstood you. Have enough key members dropped out where it can't really continue?

[avdg]

Not yet but my perspective is only reinforcing that statement as I'm sending a lot of pr myself. There are currently only 2 members that have merge access.

Given that @mishoo is busy doing other stuff and @rvanvelzen indicating that he is busy doesn't help very much. Also there are no guarantees given to solve these issues, but we should give at least give the project members some time to react. It's not that we should ask questions at their back and expect them in few seconds. That's not how things works.

Anyway, there are simply too many people depending on this project and the expectations are also very high. If there is activity, but no activity in the main repo, the attention should be shifted to those who can maintain the activity in the repo or shift to a system that allow this to happen.

[arackaf]

the attention should be shifted to those who can maintain the activity in the repo or shift to a system that allow this to happen

Exactly. The core maintainers are unpaid volunteers, so I'll never complain that they're not doing enough on this project. BUT - yeah, please please give control to others who DO have the time and ability to drive it forward. I'd really hate to see the project die for lack of people with merge rights.

React Router had a similar problem recently - they were smart enough to give control to others who deserved it - hope that happens here as well.

[rvanvelzen]

I don't believe this issue to be the correct forum for that discussion. I do have some thoughts on it, but please remember that this is @mishoo's project, not mine. ;-)

[arackaf]

@avdg - is a fork in the future? UglifyJS3 ??? :-)

[avdg]

Uh, yeah, I started this topic and should also take the blame I guess. But this project got too big and has parts I don't usually care. I realise this especially when someone random tagged me some repo rights for the grunt/grunt-contrib-uglify project (I am still unused to their code base as I don't know the constraints of the project).

Anyway, let me open a new ticket to discuss the future of uglify, which hopefully goes further than this ticket :-)

Edit: See ticket #1181

[arackaf]

@avdg - post link here, if you don't mind? Very eager to see the discussion that ensues - I frequently use Uglify and would love to see it succeed into the ES6 era.

[avdg]

I guess we can consider anything about identifier and literals as bug on the harmony branch from now on with the exception of destructuring, objects and arrays (dunno if there are issues here). There is a small likely potential bug in template strings (using a function as tagged template instead of identifier), but I wonder myself how regular it will be used for now.

So, features that may be considered completed include:

• Number literals (0b111 and 0o777)
• Unicode escape sequence (including identifiers)
• Unicode surrogates
• Template strings
• Exponentiation operator (ES2016)
• new.target

Edit: following features may follow up soon may be considered complete.

• Generators (with exception of destructuring)
• Computed properties (minifying isn't optimal yet)
• Object properties (with exception of destructuring)

Following features are being worked on:

• Binding pattern and destructuring assignment

Following features are incomplete:

• Block scoping (assign the assignment to the right scope, for example with the switch blocks)
• Import and export statements (lacking * support for import)

[grovesNL]

@avdg Thanks for all of your work on this.

I'm not sure if this is what you meant about identifier/literals, but there may be a minor regression on the most recent Harmony branch. It fails while parsing https://github.com/facebook/fbjs/blob/master/packages/fbjs/src/core/getMarkupWrap.js#L40

SyntaxError: Unexpected token: string (*) [./~/fbjs/lib/getMarkupWrap.js:40,0]

I just wanted to mention it in case it's not covered in any of the object literal tests.

[kzc]

@grovesNL Already fixed and awaiting merge: https://github.com/mishoo/UglifyJS2/pull/1229

[avdg]

Like @kzc said, luckily I did exclude objects (though that was mentioned vaguely in a sea of text).

Objects parsing isn't perfect yet and there might be more failing test cases that acts like minefields (that is, bugs that still have to be uncovered. I guess I have to dig in some other tools than test262), although bugs are addressed quite fast.

[grovesNL]

Great, thanks!

[kzc]

General ES6/harmony minification question for anyone - what sorts of scenarios are people using it for? ES6 browser market share is around 60% by my estimation.

Is anybody scanning the HTTP User-agent for ES6 compliant browsers and serving up minified ES6 instead of minified transpiled ES5 for just those users?

[klimashkin]

@kzc exactly

[danmackinlay]

Not us, for example, @kzc. We're developing an app that uses MIDI and fancy WebAudio stuff, ( https://indigo.listentocolors.net/ ) - all the browsers that support such fancy also support ES6; so there's no point bothering with ES5, ever. Generally, I expect other people who are developing webapps that require any fancy HTML5 functionality also are freed from worrying about legacy browsers. The only thing we need to serve to older browsers is a static HTML page with a sad face emoji.

[RevanProdigalKnight]

@kzc I use a general-purpose syntax support detection string that I eval in my index.html and then decide based on that result whether to load the ES6 or transpiled ES5 code into the page.

[sbrl]

In my website I'm not bothering about serving minified ES5 as it adds additional
complexity to the system. As a student I try to keep things as simple as
possible.
On Thu, 2016-07-28 at 19:46 -0700, RevanProdigalKnight wrote:

@kzc I use a general-purpose syntax support detection string that I eval in my
index.html and then decide based on that result whether to load the ES6 or
transpiled ES5 code into the page.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[raybooysen]

I want minified ES6. We are building large desktop-like apps in Electron.
The bundles get very large, these are SPAs that run for weeks at a time.

On 29 Jul 2016 02:39, "kzc" [email protected] wrote:

General ES6/harmony minification question for anyone - what sorts of
scenarios are people using it for? ES6 browser market share is around 60%
by my estimation.

Is anybody scanning the HTTP User-agent for ES6 compliant browsers and
serving up minified ES6 instead of minified transpiled ES5 for just those
users?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mishoo/UglifyJS2/issues/448#issuecomment-236073092,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAcMhaEbEFo-E7skAD__A9KAc9JfyFmvks5qaVnQgaJpZM4BpCcE
.

[chyzwar]

@kzc anyone writing SPA can afford to drop support for old browsers. Edge/Firefox/Chrome and soon Safari provides at least 92% of ES6 coverage.

[RevanProdigalKnight]

@Chyzwar Not necessarily. Thanks to the writing of the contract, I'm maintaining an SPA that needs to support IE10 (which only supports 3% of ES6) for at least another 2 years when the contract is next renewed.

[chyzwar]

@RevanProdigalKnight but would you start new SPA project with support for IE10?

Microsoft already retired IE8, 9, 10 and put nagware in 11. Babel is not a solution and it is costly abstraction.

[RevanProdigalKnight]

@Chyzwar I argued against supporting anything less than IE11 when I started writing it, the contract people wanted IE8 support (this was ~1.5 years ago, some of our clients are still running XP). As it is, I run Babel as part of the build process and serve the Babel-ified files to browsers that don't support ES6 when testing. I don't want to serve un-minified files to production environments, though, so I only serve the minified Babel-ified files there.

[MeirionHughes]

@RevanProdigalKnight I have a contracter friend that had to add IE5-7 support; I enjoyed his tears...

[papermana]

@kzc Google Chrome extension!

Having one platform to develop for and not having to worry about compatibility with browsers from 5 years ago is a wonderful feeling.

[AliMD]

Any schedule for next release with basic es2015 support ?

[avdg]

Current tendens seems to be slowed down. But we're in summer times which may explain the lack of maintainers happy to merge stuff in. Especially when that number is still 2.

[arackaf]

@avdg they haven't given you commit privileges yet? You seem to be carrying this project at this point.....

[avdg]

Not sure what @mishoo thinks about giving me commit privileges.

[avdg]

And in a good month I'll be on vacation/meeting relatives, mostly without internet for about a month.

[kzc]

A lot of those ES6 tests fail because some of the assumptions/optimizations that are valid in ES5 are not valid in ES6 - like unconditional function hoisting. Take this test for example:

https://github.com/tc39/test262/blob/master/test/language/block-scope/shadowing/dynamic-lookup-from-closure.js

It fails with default compress options but it passes with -c hoist_funs=false.

Maybe harmony should disable a number of these optimizations until they've been retuned for ES6.

[RichardJECooke]

To the author of this project, please will you add a tag to the harmony branch at each version so we can refer to it directly in our package files? I.e. "uglify-js": "github:mishoo/UglifyJS2#harmony__2_7_1".

Otherwise we have to refer to the entire harmony branch without version, so when someone updates references a month down the line she might download a version that has bugs and break our project.

[finom]

@RichardJECooke I guess you can use commit hash instead of branch or tag. Hope this helps.

[avdg]

More (computed) object property fixes should soon land in harmony. I guess I can start up investigating the failures involving binding patterns in parameters, since they are a part of a major bulk of errors on test262.

[avdg]

Actually I have found very few issues with the current generators (there is a small problem with accepting the yield keyword as property, though that needs some spec checking). Still unsure if it's production ready but feel free to try out.

[avdg]

I do now have a working prototype of binding patterns, but I'm stuck with the question if uglifyJS should support something like

(function([]){})

In chrome and firefox, it is supported, but the ArrayBindingPattern in spec doesn't seem to allow something like that.

Otherwise, binding pattern support (and later destructuring) can be followed on https://github.com/avdg/UglifyJS2/compare/harmony...avdg:binding-pattern - #1268

[mgol]

@avdg Interesting. If it's not allowed by the standard, maybe bug reports against browsers should be reported?

[mgol]

@avdg I looked into the spec and [] seems to be accepted as ArrayBindingPattern:
http://www.ecma-international.org/ecma-262/6.0/#sec-destructuring-binding-patterns
In the first production both Elision and BindingRestElement are optional, if they're both omitted, we're left with just [].

[avdg]

Ah, then it's my part being wrong. Also an already included test case has to be remove then (which made me doubt even more).

Edit: that test is removed in the patch by now

[avdg]

And yes, I overlooked that part of the spec. Indeed, it's legal syntax.

[avdg]

And thanks for the quick response.

[avdg]

Updated https://github.com/mishoo/UglifyJS2/issues/448#issuecomment-233198012 (list supported features)

[avdg]

I'll have to fix my reporter tool. Those who watched the results know that the list of errors is quite big.

But with #1268 I'm hoping to cut a big chunk of these errors which largely involves generated tests simply doing combinations with each other. These tests are like 2 dices as base case, and every test is just the combination from these 2 dices.

[SynCap]

Arrow functions as parameter to another function is not recognized
Try test with this:

    function changeTo (selector, cb) {
        [].forEach.call( document.querySelectorAll(selector), cb);
    }
    changeTo(
        'a[href^="http:"],a[href^="https:"]',
        a => { a.target = '_blank'; a.classList.add('external'); }
    );

This is work as expected code, but uglifier breaks on error: Unexpected '='.

[rvanvelzen]

On HEAD of harmony that code compresses. It _does_ add unnecessary parens around the arrow function though.

[MeLlamoPablo]

It's funny to see so many issues referencing this one. Maybe master's README.md should be updated with a warning to let people know that it doesn't support ES6, and to tell them to use the harmony branch or babel?

[lewispham]

I think the current working approach is highly inefficient and it also causes huge pressures on maintainers.

Instead of keeping testing and fixing those ES6 features, you guys maintainers should focus on releasing a version that will properly work on all the non ES6 parts (comments, whitespaces, etc). At the same time, the ES6 ones should be be left intact until their parsers are well tested. Each of them could be supported at any time in a future release. With this approach, the workload will be splitted into smaller ones and the quality will be absolutely improved as a result. Developers can still partially minify their code without having to wait for ages. Maintainers can quickly see the real life results after every release.

[avdg]

I think that is exactly what we did (although I did a lot of es5 fixes when we started the harmony branch), but es6 really is very big. The es6 grammar is about or at least twice as big. So even if es5 got maintained pretty well, it would still take some time to get es6 implemented.

Take that into account that es5 still has to be maintained with new optimization, bugs, issues and feature requests. It is not cycle that stops. Though a possible issue in this project is that we maintain the full stack js parser from parser to ast to compressor to the code generator printing the code and also the ast converters that have to be maintained as well.

I better invest my time in getting a clear status of the project. And one of the most useful tools so far are the test262, which sadly takes a lot of time to run, is hard to setup and is something I don't see a lot of developers using it.

[avdg]

I really hope #1268 will be close to being ready in one week. This should improve binding patterns and cut off a significant portion of the test262 reports.

Anyway, I'm not hurried, and I'm willing to delay merge if there are issues. But let's hope it doesn't happen too often ;-)

Edit: #1268 should be technically be finished by now. The only main part left is cleanup and review. Feel free to test it out.

[lewispham]

@avdg I don't think so. I've tried to uglify some ES6 code with this harmony branch and it has simply thrown an error on its own falsy results. That means there is no such thing like partial minification at this time. The ES6 code is still being entirely minified. Why doesn't UglifyJS just leave those it can't handle intact? So that the code can still work after being partially minified?

[avdg]

Which es6 features are you using?

[lewispham]

@avdg Most of them. Here is my exact list of features that might affect the parsers.

• for...of
• Arrow functions
• class
• let
• const
• Template strings
• Destructuring assignment
• Object initializer (shorthand property names, computed property names, shorthand method names)
• Default parameters
• Rest parameters
• Spread operator

[finom]

Hurry up guys, babel-minify is coming.

[avdg]

There are very very minor issues with template strings. But yeah they need to be fixed as well.

Destructuring is being worked on. Including default parameters and spread.

Objects literals received an update recently. Not sure if that has been taken into account.

Probably the worst bug atm is block scoping.

But meh, about other compilers becoming compressors. That also will take some time to implement.

[lewispham]

@avdg My whole point is that you and other maintainers right now shouldn't focus on fixing those ES6 bugs. IMHO, the most important thing at this time is to make partial minification possible.

[avdg]

Uh I don't want to fix the compiler afterwards with the realisation that the project was build on quicksand.

Fixing a fundamental bug late in the game is very costly as this might result in losses of already written code.

[avdg]

Please also note that despite this, that it doesn't mean there is no compression at all. Exponential expressions and computed properties can already be evaluated.

Also partial compression is better than no compression support at all (leaving those rocket scientists with 1 incompatible feature behind from using the project - on condition they are using only es approved features ofcourse)

[lewispham]

@avdg I think I've got your point. So I've decided to file a new issue on the main project.

Anyway, I think sooner or later, we should have a solution for this problem. Otherwise, UglifyJS will continuously be crashed on every new ES standard release.

[avdg]

Progress update: I think I'll work on the binding pattern on the arrow functions on the next big pr. I thought about implementing the trailing , in call arguments but they aren't available in es2016.

After the arrow functions I will take a look at modules I guess and that should be the end of implementing es2015/es2016 features. Then we'll be moving on to making things more stable, fixing the compressor and the mangler and stuff like that.

[avdg]

Got arrow binding pattern support working on test262 with an exception of few early errors (whereof some that v8 doesn't fail either when excepted to fail) (edit: uh yeah v8 does crash on them, like the tests expect them. Also there is no parameter tracker for arrow parameters like binding patterns when content have already been parsed before the parser knows it has to deal with arrow functions). Still have to look at the early errors, but the patch is functional.

A downside for pushing this patch is that it probably depends on #1268. So I wait for the other pr to be merged for now before sending the fix in current planning.

[stevendesu]

Just chiming in @avdg:

I've seen a lot of third-party libraries and open source code bases where the only three ES6 features they use are arrow functions, const, and let.

Adding support for these three would, in my personal experience, add ES6 support for about 80% of code out there.

Also, adding support for let should be fairly straight-forward from my understanding. It's basically the same as var, right?

[avdg]

For now it's the block scope related stuff that is currently not working as intended. That information is used for compression and mangler. If you don't use compression or mangler you're actually fine.

That said and having the binding pattern problem solved for the large part (I just have to fix one test, and fix small issues later involving early errors). I might want to delay modules and es6 call arguments (there are some bugs there too) support until scoping has been implemented correctly.

Let's see how difficult it actually is to fix the scoping stuff.

So my todo list now might look like:

• [x] Merge binding pattern parameter stuff
• [x] Merge arrow parameter stuff after final test and after other binding stuff got merged
• [x] Deprecate an ast node specific for computed properties just for cleanup (because the previous 2 items have dependencies on that node, this must be done afterwards)
• [ ] Remove/Change AST_Destructuring (still need research and discussion where needed)
• [ ] Fix mangler
• [ ] Fix compressor involving variables (not sure how much @kzc can take) (also I don't know how much to fix in the compressor)
• [x] Fix call arguments
• [ ] Implement/fix modules
• [ ] Fix major broken uglify stuff to make it feature complete again
• [ ] Move on to fixing other small spec bugs and eventually implement es2017.

Edit 3/12/2016: Let's see how close we can get against end of january 2016. It won't be finished for sure, but we're getting actually getting close to quite full and stable support with the default uglifyJS setup.

[bakape]

Module support can easily be put off until the very end. No current browser has them implemented. FF and Chromium still have it in early development behind flags and we likely won't see a stable implementation till the next Edge release is out.

[avdg]

I will be moving slowly into vacation mode, which means that I get into area with less internet for few weeks (I still can do stuff then, just not as good as I can now).

I do still have some fixes buffered arrow parameters and to allow detection in strict mode while parsing (apparently I need to get the strict mode in the compressor fixed as well before stuff there gets merged).

I'm hoping to get a cleanup patch up too at the end of the week (Removing AST_ObjectComputedKeyVal), but I already see some complications in the compressor so that might take a while.

Other than that, I'm already slowly exploring the compressor, so expect some fixes there involving destructuring and I hope the mangler stuff will be doable as well.

[ghost]

is there any time table to finish supporting es6 with uglifyjs ?

[avdg]

Development from my side will be slowed down for a month

[avdg]

Also see https://github.com/avdg/UglifyJS2/projects/1 for development status.

[fritx]

I've been using uglify-js#harmony with webpack@1

// package.json
{
  "devDependencies": {
    "webpack": "1.x",
    "uglify-js": "git+https://github.com/mishoo/UglifyJS2.git#harmony"
  }
}

# commands
npm install
rm -rf node_modules/webpack/node_modules/uglify-js

[bt-frog]

@fritx: Your solution worked perfectly. I specifically was running into generator token errors SyntaxError: Unexpected token: operator (*) and now build is error-free. Your second command is crucial for it to work (rm -rf node_modules/webpack/node_modules/uglify-js).

[fritx]

@bt-frog yeah, haha... There are tons of hack in our project which is built with nw.js, webpack, react, etc.. Nw.js actually supports part of es6 syntax, so we have to do such hack.

I think using postinstall script could be even more readable:

"scripts": {
  "postinstall": "rm -rf node_modules/webpack/node_modules/uglify-js"
}

[quantuminformation]

"uglify-js": "git://github.com/mishoo/UglifyJS2#harmony"

fixes it for me when doing webpack -p

thx guys

[Polve]

Thanks @fritx for the workaround, you made my day!

[avdg]

If someone found issues with computed properties with compression, pls report in #1333 when it's still open.

If #1333 got merged or closed for some reason and there are issues with computed properties, feel free to open a separate issue with [ES6] mentioned in the title.

[avdg]

Focus will now be more on getting uglify more stable on mangling, scoping and compression. Less language features will be added after #1290 got merged for the time being (with the most noticeable one being modules).

[andreialecu]

I'm seeing this error while uglifying ES6 output from TypeScript:

ERROR in admin.js from UglifyJs
TypeError: Converting circular structure to JSON
    at Object.stringify (native)
    at Object.SourceMap.toString (eval at <anonymous> (proj\node_modules\uglify-js\tools\node.js:1:0), <anonymous>:10130:47)
    at proj\node_modules\webpack\lib\optimize\UglifyJsPlugin.js:113:24
    at Array.forEach (native)
    at Compilation.<anonymous> (proj\node_modules\webpack\lib\optimize\UglifyJsPlugin.js:44:10)
    at Compilation.applyPluginsAsync (proj\node_modules\tapable\lib\Tapable.js:71:13)
    at Compilation.<anonymous> (proj\node_modules\webpack\lib\Compilation.js:567:9)
    at Compilation.next (proj\node_modules\tapable\lib\Tapable.js:67:11)
    at ExtractTextPlugin.<anonymous> (proj\node_modules\extract-text-webpack-plugin\index.js:309:4)
    at Compilation.applyPluginsAsync (proj\node_modules\tapable\lib\Tapable.js:71:13)

This happens using the harmony fork, without it it wouldn't even recognize ES6 class names. Outputing ES5 from TypeScript seems fine, but I'm using async/await which needs ES6 to transpile properly.

Not sure if there's some easy change I could do to work around it. Any ideas?

[avdg]

It might be good to create a separate issue for that with [es6] in title and a simplified example.

[avdg]

Probably time to sync up harmony with master as I'm suspecting a conflict atm.

[avdg]

Nevermind, master has been synced apparently. Thanks @rvanvelzen.

[kzc]

Found 45176 executed tests
3707 tests failed (8.21%)
2091 tests failed because of Node (4.63%)
1198 tests failed because of UglifyJS (2.65%)

Which uglify options were used?

[avdg]

It's in the report: vm.runInNewContext(UglifyJS.minify(file).code, {});

[kzc]

It's in the report: vm.runInNewContext(UglifyJS.minify(file).code, {});

I had to write a one liner to determine that compress and mangle were enabled.

[avdg]

There are multiple pr's ready for merging, please check them out and give it a thumbs up if it looks fine. Feel free to add feedback

[avdg]

Just a reminder: status is in this comment: https://github.com/mishoo/UglifyJS2/issues/448#issuecomment-245936071

[avdg]

Added stats for node 7 in the logs above.

[fulls1z3]

webpack#2 users, I'm hereby trying to help by providing detailed instructions to use the Harmony branch of UglifyJs2 with webpack:

• Fork webpack,
• On that fork, delete all branches except master,
• Clone master branch to a local folder,
• On the local folder, delete all files,
• Commit the empty local folder,
• Download the latest release (ex: v2.1.0-beta.27 at the moment)
• Extract contents of zip file to the local folder,
• On the local folder, edit forked package.json, change

"uglify-js": "git+https://github.com/mishoo/UglifyJS2.git#harmony"

to point UglifyJs2 (harmony branch) dependency to that branch.

• Commit changes,
• Finally, point webpack in your package.json to your custom fork:

"webpack": "[USERNAME]/webpack#master"

OR,

• Point webpack in your package.json to fulls1z3/webpack (ES6/ES2015 friendly webpack fork):

"webpack": "fulls1z3/webpack#v2.1.0-beta.27-harmony"

[kt215]

Thank you @fulls1z3 for sharing this. I was using webpack globally, so I had to run this too:

npm install yargs supports-color enhanced-resolve interpret tapable webpack-sources source-map uglify-js object-assign async loader-runner acorn watchpack mkdirp ajv ajv-keywords node-libs-browser -g

Then I replaced my global webpack npm folder with your webpack-2.1.0-beta.27-harmony.zip

Lastly, I replaced my global uglify-js npm folder with UglifyJS2-harmony.zip from https://github.com/mishoo/UglifyJS2/tree/harmony

[avdg]

I'm not sure how much the test262 results can be reduced apart from some syntax errors due to unimplemented features. It shouldn't be expected that UglifyJS passes all tests, but there are tests that:

• Print the body of a (in uglifyjs compressed) function.
• Declare variables above functions with the same name (which kind of gets screwed by the hoist functions compressor, mixing the order of evaluation in these tests)
• Node errors due to errors with js (future) default library

There are tests to be improved, some are mentioned like #1358 and #1372. And there might be some more tests to be fixed, although they really require 1 by 1 inspection if there is something non-obvious going on and these test262 tests won't test daily usage stuff. So we might depend more on bug reports and more testing.

I might take a look on how much bugs there are with the mangler alone (there is #1358 though) to see how much work there is. But most bugs should be compressor oriented (especially involving block scopes) now I guess...

[TheLarkInn]

@avdg @kzc What is the stability looking like currently. Reading this thread looks like people are going to awefully interesting lengths to have the harmony support for syntax like arrow functions. I'm tempted to create either a specific plugin or update to use the harmony branch if things are looking generally okay.

[kzc]

harmony generally works if compress and mangle are disabled. There are a number of block scoping issues left to sort out.

Same problem as most other open source projects - getting people to volunteer their time to work on it.

[kzc]

While some are able to minify their ES6 code correctly with uglify harmony with default compress and mangle, I'd recommend the following settings to avoid transforms known to break let and const block scoped code:

-m -c unused=0,hoist_vars=0,hoist_funs=0,if_return=0,join_vars=0,loops=0

No guarantees though.

[avdg]

I'm a bit less busy with uglifyJS now to keep coding a bit more interesting for myself. But for now the todo can be found at https://github.com/mishoo/UglifyJS2/issues/448#issuecomment-245936071. I've just added a TODO item for AST_Destructuring, as this needs a rethink and if necessary a reimplementation (preferably before implementing the mozilla ast support) for now.

But given this is an open source project, everybody can work on it. It might be worth to understand the code base a bit better by digging small pieces of the code base at a time.

[mikeerickson]

@avdg Would you mind reviewing the following issue. It seems there is already a fix for it, however, it is not merged yet (so far as I can tell) The associated issue is causing webpack to fail when uglifying...

https://github.com/mishoo/UglifyJS2/issues/448#issuecomment-245936071

[avdg]

@mikeerickson You are linking to the roadmap, not sure what exact issue you are pointing out to. Harmony is big and it still takes a lot of things to smooth out.

[mikeerickson]

Have a look at this, you will quickly see the issue

https://github.com/mikeerickson/chalk-test

[mikeerickson]

@avdg The supplied link shows an issue with UglifyJs.

[kzc]

webpack uses uglify-js which supports ES5 javascript only.

ERROR in bundle.js from UglifyJs
SyntaxError: Unexpected token: operator (>) [./~/ansi-styles/index.js:4,0]
 ~/documents/projects/dev/litterbox/es6 

Google for "webpack uglify-js harmony"

[mikeerickson]

@kzc I am guessing that I can use the 2.2 branch in place of 2.1 reference and all will be good?

[kzc]

@mikeerickson That would be a question for the webpack project.

[mikeerickson]

@kzc so much finger pointing (they point to you for the issue, you point to them for the issue).

Surely I can fix the issue locally, but seems this is a global issue that should be reviewed and less finger pointing.

Thx for time :-)

[avdg]

We can't be clearer than (spreading the message) that we have a branch for current es5 and a separate branch for es6 and later called harmony.

As long as harmony isn't stable, it won't get merged to our normal stream/branch.

[kzc]

@mikeerickson Uglify is used by dozens of projects and we have no knowledge of how to configure third party software. But since I'm a master of the google search, this is the webpack ticket you want:

https://github.com/webpack/webpack/issues/3673

Because webpack includes uglify-js which is ES5 only, it cannot use uglify harmony without forking. One solution for webpack would be to remove uglify-js from their core project and make two different plugins for Uglify. But that's up to the webpack project.

[mikeerickson]

@kzc I managed to find the above ticket by doing the search as you originally stated.

But, I do appreciate the extended information in your second paragraph, that was the key to making it all click for me.

I appreciate the time and energy ;-)

[McPo]

@mikeerickson If you are having issues with ES6 code and UglifyJS, your best bet is to transpile it to ES5. Looking at your webpack.config you currently only transpile your code (you exclude node_modules). I assume you may be using a dependency which hasn't been transpiled to ES5 and its causing you grief.

Add the following to your loaders section

{
      test: [/node_modules[\\\/](?:dependencyA|dependencyB)[\\\/]lib[\\\/](?:.+).js/],
      loaders: ['babel-loader']
},

Replacing dependencyA and dependencyB with the dependencies your having an issue with.

If that doesn't work, create an issue in your project detailing the issue and link this issue. Or create a post on StackOverflow.

Im only posting this solution here as I too ran into this issue when I was starting out a couple months back and ended up watching this issue. Others may come here looking for the same solution.

[mikeerickson]

@McPo Thanks for your input, it is appreciated. I have been battling with this issue for the better part of this week. It seems this issue has the crux of the problem (and solution)

[mikeerickson]

@McPo FWIW, this problem manifested itself when upgrading ansi-styles from 2.2.1 to 3.0 (this is form some Chalk 2.0 stuff)

[avdg]

Hmm reading about webpack, uglifyjs is considered outdated already.

uh, nvm. They don't want the package.json with 2 uglifyjs references... and prefer to split the uglifyjs package from the main package instead.

[mikeerickson]

@avdg I need to figure out how to "disable" UglifyJs so that webpack does not try to use it, and instead use babel-preset-babili

{
  "presets": ["es2015"],
  "env": {
    "production": {
      "presets": ["babili"]
    }
  }
}

ERROR in bundle.js from UglifyJs
SyntaxError: Unexpected token: operator (>) [./~/ansi-styles/index.js:4,0]

[kzc]

@mikeerickson This is not a webpack support forum.

[avdg]

Sorry, I don't use webpack.

[mikeerickson]

@avdg Well then, no problem :-)

[mikeerickson]

@kzc I am well aware of that, just trying to get this working. I appreciate your input, no need to get all crazy :-)

[kzc]

Hmm reading about webpack, uglifyjs is considered outdated already.

People aren't going to wait for UglifyJS2#harmony to be released when there are other working ES6 minifiers - especially since babili ships with babel already.

The other minifiers produce roughly the same size code. The main advantage that uglify has is its speed. See: https://github.com/babel/babili#benchmarks

[mikeerickson]

@kzc I am all for using babili if I can get it working. I am trying to figure out how to disable UglifyJs right now so that babili can do its thing.

[andrewdavidcostello]

Apologies to the uglify guys as I know this isn't the place to put Q&A on Webpack.

@mikeerickson I would post a question on StackOverflow or similar with more details of your issue. I had a similar issue to you and we ended up transposing everything to ES5 instead of ES6 until harmony becomes stable.

In our dev config we omit:

new webpack.optimize.UglifyJsPlugin({
    compress: {
        warnings: false
    }
}),

That said...

Looking at your code however you seem to be running webpack -p aka production which runs

--optimize-minimize --optimize-occurrence-order

https://webpack.github.io/docs/cli.html

[mikeerickson]

@andrewdavidcostello In short...

You are saying if I dont call webpack -p and instead use webpack and the associated plugin things should work?

[mikeerickson]

@andrewdavidcostello Just tried what you said and still receive the error.... Thx for suggestion

[andrewdavidcostello]

@mikeerickson

You changed:

"scripts": {
    "build": "webpack -p"
  },

to

"scripts": {
    "build": "webpack"
  },

? If so then I am not sure what else to try other than defining plugins perhaps directly in your config as an empty array. If that fails post a question more relevant to Webpack as above.

plugins: []

[mikeerickson]

@andrewdavidcostello Yes, that is what I did...

However, I just found a solution

https://www.npmjs.com/package/babili-webpack-plugin

[avdg]

Short status summary: https://github.com/mishoo/UglifyJS2/issues/1433#issuecomment-274252260

[Vizer]

Hi guys,
Any updates on this?

[avdg]

I will have less time to do patches for uglifyjs. Don't expect much from my side.

[ShenZhouHong]

The version of UglifyJS shipped with the NPM module does not support template strings, as discussed here. Is there any workaround that would allow me to use template strings, or perhaps load a development version that has support?

Many thanks in advance.

[NoNameProvided]

You can use "uglify-js": "git+https://github.com/mishoo/UglifyJS2.git#harmony" in your package.json

[piotr-cz]

Or "uglify-js": "github:mishoo/UglifyJS2#harmony-v2.7.5" for specific release so npm doesn't try to keep up with latest commit on _harmony_ branch

update: npm still shows package as outdated

[graingert]

FYI you can get the latest stuff from https://www.npmjs.com/package/uglify-js-harmony with thanks to @hamosapience

harmony branch will now be published on https://www.npmjs.com/package/uglify-es

[graingert]

@monolithed why the :-1:

[monolithed]

@graingert, because your solution does not work for me. "uglify-js": "git+https://github.com/mishoo/UglifyJS2.git#harmony" woks fine

[graingert]

@monolithed you probably have another package with a peer dep on the name 'uglify-js'

[monolithed]

@jhabdas, @graingert, I have already tried rm -rf node_modules, and got the same error.

[graingert]

@monolithed the same error as...?

[monolithed]

@graingert

[graingert]

@monolithed that's because webpack depends directly on 'uglify-js'

[monolithed]

@graingert, so is there any way to fix it? )

[graingert]

@monolithed not without a fork of https://github.com/webpack-contrib/uglifyjs-webpack-plugin

[monolithed]

@graingert, I got it, thanks anyway. I upvoted your comment.

[jiaojinqian]

babili-wepback-plugin

[avdg]

Might do another test262 run tomorrow, promised!

[finom]

When it's going to be officially published?! I watch this thread for 2 years.

[avdg]

Standard keeps adding stuff ;-) It's hard to keep em satisfied ;-)

(well to be honest, harmony was big and there was no interest for an actual implementation in uglify from the start)

Be glad we have good test coverage though. We will be shipping with at least some quality and maintainability if we can keep progress.

[finom]

@avdg it looks like ECMAScript 6 standardization years ago :)

Why not to publish features by turns? Everything looked stable a year ago. It's 2017 guys, it's time :)

[avdg]

Hey, we want to ship quality :-)

[finom]

It's OK but why not to publish at least a tag with harmony version to NPM registry? It's widely used practice to publish unstable things at "next" tag. I don't like the idea to use unofficial packages like this: https://www.npmjs.com/package/uglify-js-harmony but we all use them as we use npm install github:mishoo/UglifyJS2#harmony.

[graingert]

@avdg any way of generating a config file suitable for compat-table and babel-preset-env to consume?
That way babel can target uglifyjs-harmony

[avdg]

It shouldn't be too hard (but the code needs to be cleaned up too) just change some commands in the scripts, but it's something I don't want to invest my time in now.

I only quickly created this script just to get something useful from test262.

[avdg]

Well, at least if you are talking about my testing script.

[rjdestigter]

Is there a check list of ES6 supported features by the harmony branch somewhere? UglifyJs#harmony isn't liking this syntax for me atm:

const foo = ({ bar = 10 } = {}, baz = {}) => {}

Edit: Found https://github.com/webpack-contrib/uglifyjs-webpack-plugin/issues/2

[avdg]

Destructuring and modules seems to be not fully functional. Otherwise, we're actually close to fully support parsing all other es6 features (although with little bugs, see the bold failures in the test262 logs). Compression might have issues with scoping.

[avdg]

There are apparently also still issues with the arrow function as well.

[avdg]

Those interested in the script I use, it's on https://github.com/avdg/UglifyJSMonitor.

There are improvements to make. I'm not interested in implementing them, but rather in getting an overview on what is best for all projects depending on it (mainly tools that have to compare results before and after compilation to see if anything broke).

Feel free to create issues on that repository.

[tonyc726]

I use webpack2, when uglifyjs work stage, it's call me these error

ERROR in assets/scripts/xxxxx.js from UglifyJs
Unexpected token: operator (>) [assets/scripts/xxxxx.js:*,*]

thank this issue, i solve my problem use UglifyJS2#harmony and uglifyjs-webpack-plugin.

yarn add git://github.com/mishoo/UglifyJS2#harmony -D
yarn add uglifyjs-webpack-plugin -D

webpack2 config:

import UglifyJSPlugin from 'uglifyjs-webpack-plugin';
....
plugins[
    new UglifyJSPlugin({
      compress: {
        warnings: false,
      },
      output: {
        comments: false,
      },
    }),
]

[fritx]

I've been using uglify-js#harmony with webpack@1
---- https://github.com/mishoo/UglifyJS2/issues/448#issuecomment-248939685

With npm3+ the above solution doesn't work any more, if you install another module, the uglify-js will be replaced again by npm.

For anyone who needs to use uglify-js#harmony with webpack 1.x, you can install my fork :joy:
https://github.com/fritx/webpack/tree/1.x-harmony
in which uglify-js is linked to git+https://github.com/mishoo/UglifyJS2.git#harmony

{
  "devDependencies": {
    "webpack": "git+https://github.com/fritx/webpack.git#1.x-harmony"
  }
}

[avdg]

The few patches that are merged after testing would already make more tests succeed already. Probably need another run (I very likely don't have time for this tomorrow).

[avdg]

Yes, lots more tests are passing now https://gist.github.com/avdg/c72693832948e4725acea58fa6d10342. An improvement of 152 tests compared to the previous one :-)

[elsurudo]

Good to see there is some progress being made... thanks! Any idea of an ETA?

[sdesmond]

Alas, poor Uglify! I knew it. A program of infinite possibilities, of most excellent fancy: it hath borne me on its back a thousand times; and now, how abhorred in my imagination it is! Here hung the code that i have used I know not how oft. Where be your arrow functions now now? your lets, your block scoping? Three years hence opened this issue, I must compress my code. I must use Babel Minify.

Thanks for all the good times Uglify!

[avdg]

@elsurudo there is no breakdown on the most important issues. No planning, no ETA. Obviously we need to fix bugs.

There is still this though: https://github.com/avdg/UglifyJS2/projects/1

[alexlamsl]

harmony branch will now be published on https://www.npmjs.com/package/uglify-es

Closing as the scope of this issue is too broad. Please file reports on specific issues from now on, with [ES6] prefix and actionable details.

[graingert]

@hamosapience can you deprecate https://www.npmjs.com/package/uglify-js-harmony in favour of uglify-es?

[hamosapience]

Sure:
https://www.npmjs.com/package/uglify-js-harmony.
Looks pretty deprecated now)

[graingert]

@hamosapience you want to run:

npm deprecate uglify-js-harmony "deprecated in favour of uglify-es"

[mgol]

@hamosapience you made a typo in the message; it says "depreceted" instead of "deprecated". Also, it directs people to uglify-js which is the stable version that doesn't understand ES6. It'd be better to mention uglify-es.

[Martii]

@alexlamsl

Re current README.md currently states npm install uglify-js -g which doesn't seem completely synonymous with:

harmony branch will now be published on https://www.npmjs.com/package/uglify-es

So which npmjs.com source is correct... https://www.npmjs.com/package/uglify-es or https://www.npmjs.com/package/uglify-js ?? e.g. they both point to uglify-js for npm installation... which can be confusing to newer users.

Thanks for the look.

[graingert]

@Martii both are correct, uglify-es is the Harmony branch, and uglify-js is the master branch

[Martii]

@graingert
So the https://www.npmjs.com/package/uglify-es page at npmjs.com is reading the master here on GH then... since it says to install with npm install uglify-js -g e.g. it should say npm install uglify-es -g.

---

Should be...

• ES5 → https://www.npmjs.com/package/uglify-js → https://github.com/mishoo/UglifyJS2/blob/master/README.md
• ES6+ (ES2015+) → https://www.npmjs.com/package/uglify-es → https://github.com/mishoo/UglifyJS2/blob/harmony/README.md

... but is currently ...

• ES5 → https://www.npmjs.com/package/uglify-js → https://github.com/mishoo/UglifyJS2/blob/master/README.md
• ES6+ (ES2015+) → https://www.npmjs.com/package/uglify-es → https://github.com/mishoo/UglifyJS2/blob/master/README.md

Cc: @isaacs ... is there a way to have npmjs.com read the harmony branch README.md correctly? Thanks for the visit in advance.

[alexlamsl]

Documentation for uglify-es has been updated for 3.0.3, which is yet to be published on npm pending green light from Travis.

[sbrl]

Suggestion: Set up Gitter for general discussion if you haven't already, and then put a link in the README to it.

[Polve]

I'm unable to understand how to correctly integrate uglify-es with the usual ember build pipeline: a few weeks ago I just had to add the dependency "uglify-js": "git://github.com/mishoo/UglifyJS2#harmony" but this not work any more.

I tried removing ember-cli-uglify and depending instead by ember-cli-uglify-es but this not seems to work too.

Can anyone please give me an hint?

[avdg]

Note that the api has been changed on harmony because of the breaking changes. This is done as preparation for uglifyJS v3.

[fritx]

@Polve if you're using webpack@1 and mishoo/UglifyJS2#harmony and have met the uglify-es problem, then you must be in the same trouble as I was.

You could try my fork of webpack and re-install, it would help.
https://github.com/fritx/webpack/tree/1.x-harmony
as mentioned here https://github.com/mishoo/UglifyJS2/issues/448#issuecomment-290904206

npm i -D "git+https://github.com/fritx/webpack.git#1.x-harmony"

This fork is including uglify-js < 3, and can work well.

[Polve]

I'm not using webpack, and I'm still stuck, unable to create a production build :-(

[kzc]

I'm not a webpack user, but you could try:

https://github.com/noBlubb/uglify-es-webpack-plugin

[tetreault]

In comparison Sputnik 1 was pretty much designed in 3 years and launched if Wikipedia isn't lying to me.

[isaacs]

Hey. npm doesn't read the readme.md file from GitHub. It reads the local file at publish time. To change it, publish a new version.

[alexlamsl]

@isaacs thanks for the confirmation. I believe this has been taken care of in https://github.com/mishoo/UglifyJS2/issues/448#issuecomment-300418754

[Martii]

npm doesn't read the readme.md file from GitHub. It reads the local file at publish time.

That explains a bit. Thanks.

[Bagma]

Does someone know how to integrate uglify-es in grunt project?

[ghost]

Sounds like a great question for stack overflow

[alexlamsl]

@Bagma use the harmony branch of grunt-contrib-uglify:
https://github.com/gruntjs/grunt-contrib-uglify/tree/harmony

[kzc]

use the harmony branch of grunt-contrib-uglify:
https://github.com/gruntjs/grunt-contrib-uglify/tree/harmony

Is there an official grunt-contrib-uglify npm package for uglify-es?

[ghost]

RTFM

[kzc]

@alexlamsl Since uglify-es has been released as the npm package for the uglify harmony branch, can this thread be closed to comments?

[alexlamsl]

@kzc sure thing :+1: