Rich Harris

This already happens in simple cases: ```js // input function foo () { console.log(1); return; console.log(2); } // output function foo(){console.log(1)} ``` But it fails if there's a declaration after...

More advanced version of #104 and #105: ```js // input function foo () { function bar () { return 42; } var answer = bar(); console.log(answer); } // output function...

```js // input if ( x ) { foo = 1; } else { foo = 2 } // output x?(foo=1):(foo=2) // better output foo=x?1:2 ``` ```js // input if...

```js // input function foo () { function bar () { console.log(42); } bar(); } // output function foo(){function a(){console.log(42)}a()} // better output function foo(){console.log(42)} ``` I think this basically...

If a variable has a literal value then in many cases it makes sense to inline the value, rather than declaring the variable: ```js // input var COUNT = 99;...

`(function () {}()}` can have no effect, and should be removed

Mangle property names

4

This can have a substantial impact on generated code size. Would like it to be automated though — no annotations or white/blacklists, instead Butternut should ideally be smart enough to...

If there's an `import`/`export` declaration, we know that this is a module and that it's therefore safe to a) mangle/remove top-level declarations, and b) remove 'use strict' pragmas. Probably makes...

Unused identifiers in object/array patterns are not removed

8

*Edited: no longer a bug, but suboptimal output* ```js // input (function () { var {foo,bar} = obj; console.log(foo); }()) // expected !function(){var {foo:a}=obj;console.log(a)}() // or maybe !function(){console.log(obj.foo)}() // actual...

Mangling function/class declaration names is dangerous

2

Code might refer to `fn.name`. Uglify, Closure and Babili all mangle function names by default, so *maybe* we should too. Either way we should certainly have the option to preserve...