Alex Lam S.L.
Alex Lam S.L.
Another data point is that `collapse_vars` doesn't seem to interfere with `/*@__PURE__*/`: ```sh $ echo 'function f(){ var a=fn(); a(b()); }' | node bin\uglifyjs -c function f(){fn()(b())} $ echo 'function...
> Let's just keep the behavior as is for now, but leave the ticket open while we consider the issues involved and see if it impacts any real world code....
Another idea would be `pure_funcs: true` by default for `/*@__PURE__*/`, though it gets complicated when you have custom `pure_funcs` but would like to disable the annotations.
The uglified numbers look positive for starters. I suspect the worse gzipped results are (partly) due to `mangle` – one way to assess is to run without it: ``` node...
Re-reading https://github.com/mishoo/UglifyJS2/issues/2585#issuecomment-351479601 it claims to produce **post-gzip** improvements, which is not observed anywhere (except `bootstrap.js`) - so I'm not sure how that was done.
Here's a more restricted version which never introduces new variables, i.e. only group `void 0`s into an existing variable which happens to be `undefined`: ```diff --- a/lib/compress.js +++ b/lib/compress.js @@...
Introducing new variables tend to cause cascading effects on variable name assignments within `mangle`, which is why such a large gzip delta can be observed with a seemingly small change....
And yes, putting that new variable first in the first `var` would shift the names of all subsequent declarations in the scope, so has a bigger effect than a trailing...
FWIW, `inline>1` also had to fight with `gzip` regressions back then via various tricks and hacks to make it profitable.