Age | Commit message (Collapse) | Author |
|
Close #542, #641, #647
|
|
(even if --mangle-props is not there)
|
|
Close #670
|
|
|
|
|
|
|
|
tools/domprops.json
|
|
|
|
|
|
... and support storing there variable names as well, to help with multiple
invocations when mangling toplevel.
|
|
|
|
We only touch properties that are present in an object literal, or which are
assigned to. Example:
x = { foo: 1 };
x.bar = 2;
x["baz"] = 3;
x[cond ? "qwe" : "asd"] = 4;
console.log(x.stuff);
The names "foo", "bar", "baz", "qwe" and "asd" will be mangled, and the
resulting mangled names will be used for the same properties throughout the
code. The "stuff" will not be, since it's just referenced but never
assigned to.
This *will* break most of the code out there, but could work on carefully
written code: do not use eval, do not define methods or properties by
walking an array of names, etc. Also, a comprehensive list of exclusions
needs to be passed, to avoid mangling properties that are standard in
JavaScript, DOM, used in external libraries etc.
|
|
|
|
`-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 #495
Close #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.
|
|
|
|
Passing `--keep-fnames` will enable it both for compressor/mangler, so that
function names will not be dropped (when unused) nor mangled.
|
|
|
|
|
|
Close #288
|
|
|
|
|
|
for now only used for keys passed to `-c` or `-b`.
|
|
i.e. read `-c unsafe,unsafe-comps` as `-c unsafe=true,unsafe_comps=true`
|
|
Close #335
|
|
Fix #333
|
|
|
|
|
|
|
|
|
|
|
|
|
|
See: https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit
The spec was updated on May 16th since `//@` was causing some issues with IE.
|
|
|
|
|
|
5af144522a6fea302abdd0b63d48864de0664207
|
|
|
|
synchronously.
|
|
doesn't break IE9+
|
|
|
|
Previously:
Without `--screw-ie`, UglifyJS would always leak names of function
expressions into the containing scope, as if they were function
declarations. That was to emulate IE<9 behavior. Code relying on this
IE bug would continue to work properly after mangling, although it would
only work in IE (since other engines don't share the bug). Sometimes
this broke legitimage code (see #153 and #155).
With `--screw-ie` the names would not be leaked into the current scope,
working properly in legit cases; but still it broke legit code when
running in IE<9 (see #24).
Currently:
Regardless of the `--screw-ie` setting, the names will not be leaked.
Code relying on the IE bug will not work properly after mangling.
<evil laughter here>
Without `--screw-ie`: a hack has been added to the mangler to avoid
using the same name for a function expression and some other variable in
the same scope. This keeps legit code working, at the (negligible,
indeed) cost of one more identifier.
With `--screw-ie` you allow the mangler to name function expressions
with the same identifier as another variable in scope. After mangling
code might break in IE<9.
Oh man, the commit message is longer than the patch.
Fix #153, #155
|
|
The problem with reading synchronously from /dev/stdin is that you can get a
spurious EOF when the input buffer is empty, even if more content is coming. Now
STDIN is read from a loop, and only stops polling when all input has been read.
This fixes #70 #85 and other errors related to parsing large files on STDIN.
|
|
For now the implication is that UglifyJS will not leak a function
expression's name in the surrounding scope (IE < 9 does that).
(ref. mishoo/UglifyJS#485)
|
|
|
|
Fix #100
Fix #47
|
|
|
|
|
|
It breaks usage like this:
echo '...code...' | uglifyjs
This reverts commit e48802ad291fae5a16f2d23cbd25a0c433cdbe48.
|
|
|
|
|
|
(for more fair comparison to Closure compiler)
|