Harmony support
ozanmakes opened this issue · comments
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 }).
Any comment on this?
That would be great to have, ES6 brings a lot of important new features but minification of all of them is still needed.
+1
+1
👍
+1
👍 just got bit by for...of.
If harmony support were enabled, we could also safely convert functions that don't use this to use the => syntax as well.
+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.
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).
@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. :)
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?
👍 bump.
👍
👍
👍
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
+1
👍
👍
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.
Like most clearly expressed priority of issue
You can even sort by "Most commented"
@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. :)
Maybe we should start with this question as we can all learn things from each other:
What is your favorite es6 feature?
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.
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.
I have to agree with @Martii; let will be a huge plus for temporary loop variables.
What is your favorite es6 feature?
generators ftw!
co + generators + promises ♡
@artin-phares Awesome!
👍
👍
I'm curious if there's some sort of status page tracking which ES6 features are yet implemented. Like this, over at Esprima.
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 jquery/esprima#1099
—
Reply to this email directly or view it on GitHub
#448 (comment).
+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
Note ECMAScript 6th Edition (ES6 a.k.a Harmony) was finalized relatively recently last month.
See also:
What is your favorite es6 feature?
Please add support for classes and let!
By the way for anybody reading this, just use Babel.io before you use Uglify, it would work
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.
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
@probins I started work on that, but it currently depends on my pull request for arrow functions being accepted.
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?
I didn't create it yet after all, it was dependent on whether my other pull request was accepted. I'll send it soon
@mzgol Atleast it works for now, I don't really see this feature getting added to Uglify soon
@rvanvelzen when is the next release planned? Can't wait to use arrow functions with uglify 😄
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.
@fabiosantoscode Do you have any list of anticipated features?
@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?
@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.
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.
Of those features you listed, these are the ones not done yet:
class
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.
@fabiosantoscode my vote is for class and let!
for (object of objects) e.g. the of
@Martii got that working in the harmony branch
@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.
@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.
+1 👍
+1
+1
@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/'));
+1
+1
Chill, everyone. This is being worked on
good news
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!
@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.
@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 ;)
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.
@Sasstraliss Watch a few comments above (#448 (comment))
@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.
@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.
@fabiosantoscode
We're currently running on npm@2.x so it shouldn't be too difficult but if node updates to npm@3.x , 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.
+1
What is your favorite es6 feature?
Generators!
Could we please get an updated list of what's still left before the harmony branch is ready?
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.
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.
@buunguyen What do you mean by "generators can't be transpiled"? They sure can.
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.
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
@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.
It doesn't look like there's really anything that can be minified in an import statement...
@RevanProdigalKnight Err... variable names?
@RevanProdigalKnight @fabiosantoscode There's active development going on in the v8 engine on destructuring: https://bugs.chromium.org/p/v8/issues/detail?id=811
@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";@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"
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'
@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. :)
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.
@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 #821
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 notifications@github.com 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
#448 (comment).
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.
How can I report an issue that's related to harmony branch?
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.
@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.
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)
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 notifications@github.com 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
#448 (comment).
@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.
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
There can be only one node_modules/uglifyjs
That's definitely one of the issues with npm@3.x ... we are currently on npm@2.x 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 npm@3.x 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. ;) :)