Open harai opened 2 months ago
Thanks for the report − investigating.
So it turns out to be a strict-mode bug/feature of Node.js / V8, i.e. if you add "use strict";
to the uglified output above, it will produce the correct output.
Which web browser were you running the output code on?
For a quick workaround in your use case, add --no-module
to the command line:
$ uglifyjs work/test.js --no-module --compress --keep-fnames -b --output work/test.min.js
@alexlamsl
So it turns out to be a strict-mode bug/feature of Node.js / V8, i.e. if you add "use strict"; to the uglified output above, it will produce the correct output.
This page says the same thing:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode
Which web browser were you running the output code on?
I was using the latest version of Chrome.
--no-module
option seems to be used to support old JS runtime.
The code above is part of WooCommerce 9.3.2. Download the zip file and you will find the code in woocommerce/assets/client/admin/navigation/index.js
.
The file was automatically re-minified with UglifyJS during optimization process on my server and caused the issue. The real command used for the auto-minification process is:
uglifyjs "$INPUT_JS" --compress --mangle --keep-fnames --source-map "$SOURCEMAP_CONFIG" --output "$OUTPUT_JS"
--no-module
option seems to be used to support old JS runtime.
With latest (& greatest?) ES module "strict" mode is supposed to be implicit:
Also, note that you might get different behavior from sections of script defined inside modules as opposed to in standard scripts. This is because modules use strict mode automatically.
So I guess the reality is that somehow Chrome still runs your code in "sloppy mode", hence the need for --no-module
in this case.
Thank you so much for your hard work and for taking the time to respond! I’ve encountered the same issue and understand that it’s related to the behavior of "use strict". However, I believe this could still be considered a minor flaw.
Here’s the original source code:
window.mini_regClass = window.mini.regClass = function (clazz, className) {
var args = [clazz];
var exts = mini.getEpointExt(className);
if ($.isArray(exts) && exts.length) {
$.each(exts, function (i, ext) {
args.push(ext);
});
mini.overwrite.apply(mini, args);
}
return old_regClass.apply(this, arguments);
};
After:
window.mini_regClass = window.mini.regClass = function(t, e) {
var i = [t],
t = mini.getEpointExt(e);
return n.isArray(t) && t.length && (n.each(t, function(t, e) {
i.push(e)
}),
mini.overwrite.apply(mini, i)),
s.apply(this, arguments)
}
I’d like to suggest a possible improvement to avoid this behavior. Specifically, local variables could use names that don’t overlap with parameter names.
For example, in version 3.13.5(I'm not sure what the correct last minor version is), the result was correct and looked like this:
window.mini_regClass = window.mini.regClass = function (t, e) {
var i = [t],
n = mini.getEpointExt(e);
return (
aI.isArray(n) &&
n.length &&
(aI.each(n, function (t, e) {
i.push(e);
}),
mini.overwrite.apply(mini, i)),
bI.apply(this, arguments)
);
};
My source code has a long history—maybe two to three times longer than my own work experience—so I’m not entirely sure how "use strict"
might affect it.
I trust that uglify-js is continuously improving, and as long as there are no breaking issues, I’m willing to keep updating it within minor versions.
I didn't notice, maybe I can use {module: false}
to avoid it
Uglify version (
uglifyjs -V
)JavaScript input
The
uglifyjs
CLI command executed orminify()
options used.Disable most compress options and enable
merge_vars
,reduce_vars
,unused
, andvarify
.JavaScript output or error produced.
t
is reassigned just before getting its value witharguments
keyword, which results inError: Failed to execute 'replaceState' on 'History': CustomEvent object could not be cloned.
error.