Update uglify

[gagern]

Our version of uglify is some pretty ancient 1.0.7. Working on #3326 I noticed in particular that it only generates \u???? escapes in string literals, never \x?? where that is possible. mishoo/UglifyJS@81f5efe from two years ago fixed that. On the other hand, reading the history of that directory I see that there were quite a number of customizations to the code. This suggests several possible approaches.

1. Keep the code base in emscripten as is, only cherry-pick selected features as the need arises
2. Make an effort to cherry-pick as many featurs and fixes as possible into the emscripten tree
3. Set up a branch of uglify-js, and replay emscripten changes in there, dealing with conflicts as they arise, then use one of the following ways to include that into the emscripten tree
4. Commit a plain vanilla npm install of uglify-js, then check which of the modifications are still required
5. Commit a plain vanilla npm install of uglify-js and hope that all custom modifications are no longer needed, or that if this still breaks anything then we have a test case to detect that breakage
6. Make uglify-js (and its dependencies?) submodules of the emscripten git repository
7. Drop uglify-js from the emscripten repository, and use npm to install it and its dependencies (where would such an npm call go, since we have no top level Makefile or similar?)

Personally, I consider having a third party npm project committed to the emscripten code tree to be a bad thing. I'd prefer an npm call to install things. I guess that any features we need, others might need as well, so if there is anything to be modified, we should try to get those modifications included upstream. Until then we could let the package.json refer to a github commit on some branch which includes the neccessary features.

Here is a closer look at all the commits which affect that directory:

• 4d12c91 Added a redundant-variable eliminator script and its dependencies.
  Initial import, including coffeescript as a dependency.
• 536bad1 Updated UglifyJS to preserve object key quotedness (Closure Compiler compatibility).
  Do we want to run closure after uglify, or rather instead of uglify?
• c746d20 Made sure uglify's code generator re-parenthesizes anonymous functions.
  Current uglify apparently does that.
• be2dafa Coffee-script fix for new node.js
  86c9095 update coffeescript to d8905e2
  a79d611 remove no longer needed coffeescript
  2d9ed25 kill symlinks to coffeescript
  Current uglify no longer uses coffeescript.
• 0c3cb93 Delete uglify code that was only needed for compression.
  0f73e28 Map source lines for assignment statements.
  d680f5e Implement source maps for optimized builds.
  5459b35 Fix line numbering for invoke instructions.
  7212198 Make optimizer handle both strings and string-like type objects.
  4eef4be Put uglify back the way it was.
  88feddf Get test_source_map passing again.
  5664470 Move line numbers to the AST node itself.
  All from Source maps (Refs #1252, Reopens #1267) #1274, requires a closer look to see whether we can avoid modifying uglify for this.
• ffb887d add a newline to source comments in uglify, where necessary
  Still have to work out the use case here, but I doubt it's still an issue with current upstream.

[kripken]

Note that Uglify and Uglify2 are different projects. I believe 2 has a different AST, which would make it hard for us to switch to it. And 1 has not seen much work, so I'm not sure updating it would help us.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past 2 years. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.