catch identifier is mangled correctly for ES5 standards-compliant JS engines by default.
Unconditionally use the ie8 if/do-while workaround whether or not --screw-ie8 is enabled.
To support non-standard ie8 javascript use: uglifyjs --support-ie8
The option added in fbbaa42ee5 wasn't
being respected inside object literals, so quoted property names would
still be stripped out with this option.
This is mostly a corner-case, but useful when the output is passed to
something like the Closure compiler, where quoted property names can be
used to prevent mangling.
* Don't interpret strings with escaped content as directive
* Don't interpret strings after empty statement as directive
* Adapt output to prevent strings being represent as directive
* Introduce UGLIFY_DEBUG to allow internal testing like EXPECT_DIRECTIVE
It's now available during tree walking, i.e. walker.has_directive("use
asm"), rather than as part of the scope. It's thus no longer necessary
to call `figure_out_scope` before codegen. Added special bits in the
code generator to overcome the fact that it doesn't inherit from
TreeWalker.
Fix#861
`-q 0` (default) use single or double quotes such as to minimize the number of
bytes (prefers double quotes when both will do); this is the previous
behavior.
`-q 1` -- always use single quotes
`-q 2` -- always use double quotes
`-q 3` or just `-q` -- always use the original quotes.
Related codegen option: `quote_style`.
Close#495Close#460
Some `yargs` guru please tell me why `uglifyjs --help` doesn't display the
help string for `-q` / `--quotes`, and why it doesn't output the expected
argument types anymore, like good old `optimist` did.
`\uFEFF` (ZERO WIDTH NO-BREAK SPACE) is removed when parsing, but was
un-escaped for the output when `ascii_only` was false.
When using
UglifyJS multiple times (creating packages from minified sources, for
example), this would lead to problems because the byte was removed when
parsing for the second time.
NaN and Infinity were replaced in the output generation, instead of
during compression. This could lead to results where `1/0` was inserted
without parens leading to invalid output.
The nodes are replaced in the compression step now, and the output
generation returns their regular names. This should not be a problem,
since they're already only constructed from the original name.
As `maybe_newline()` is only called when `might_need_semicolon` is `true`, the `max_line_len` option has no effect for files without (or with very few) semicolons (like JSON files). A simple for this problem is to use `maybe_newline()` instead of `noop` as the `newline()` function in non-beautify mode.
