Uglifyjs: Error parsing arguments for flag `b' 2.8.15

[noyobo]

version 2.8.15

--compress unused=false,warnings=false --beautify beautify=false,ascii-only=true --mangle

Error parsing arguments for flag `b': beautify=false,ascii-only=true

2.8.14 it work

[alexlamsl]

@noyobo thanks for the report. The shorthand ascii-only is broken, but if you use the original name ascii_only it would work.

@kzc #1627 does not account for the magic in bin/uglifyjs which parses ascii - only = true then textually replaces the hyphen. I think it's best to patch up bin/uglifyjs in this instance (and then add a test to guard this behaviour)?

[alexlamsl]

The alternative is to add if (!options.strict) return true; back into is_assignable(), then investigate whether it's safe to flip options.strict to true by default.

[alexlamsl]

options.strict is for optional semi-colons and trailing commas, which are valid JavaScript constructs unlike ascii - only = true

So to answer my own question, no they should not be under the same flag even if we were to reinstate this relaxed parsing functionality.

[noyobo]

This can be understood as a historical burden? Beautifier options There are many styles of parameters. like:

quote_style keep_quoted_props indent-start ascii-only

Whether it is necessary to continue to be compatible with writing, or uniform style (use _) ？

[alexlamsl]

Much as I'd like to, I think we can't drop this hyphen short-form until 3.x

[noyobo]

I understand, but can you publish a fix release to fix this problem?

Because it's a broken change.

I have a lot of clients that can not work properly, Thank you.

[alexlamsl]

Pull request is always welcome.

[kzc]

#1627 does not account for the magic in bin/uglifyjs which parses ascii - only = true then textually replaces the hyphen.

I was unaware of that. We have to probably should support that legacy CLI behavior.

The alternative is to add if (!options.strict) return true; back into is_assignable()

Can a new parse option cli be created just to overcome this CLI getOptions() hack and passed to this line in bin/uglifyjs?

[noyobo]

I do not know how to fix the bug in a short time.

[alexlamsl]

@kzc

I was unaware of that.

Then you fared better than I did. I knew that when I worked on #1490 yet I failed to connect the dots.

We ~have to~ probably should support that legacy CLI behavior.

Agreed, though we can revisit this breaking decision in 3.x

Can a new parse option cli be created just to overcome this CLI getOptions() hack and passed to this line in bin/uglifyjs?

Agreed with a new option _if_ we were to reintroduce such behaviour. Though the more I think about it, the more I'm wondering why a simple String.split() then UglifyJS.parse() on the values alone can't suffice. That way the parser doesn't need to accommodate non-JavaScript syntax.

Either case, let me dwell on this for a while, as I'd like to find an elegant solution as opposed to an ugly hack.

[kzc]

@noyobo @alexlamsl Is this patch sufficient to address the problem?

diff --git a/bin/uglifyjs b/bin/uglifyjs
index e39a4b4..635ca36 100755
--- a/bin/uglifyjs
+++ b/bin/uglifyjs
@@ -561,7 +561,7 @@ function getOptions(flag, constants) {

         var ast;
         try {
-            ast = UglifyJS.parse(x, { expression: true });
+            ast = UglifyJS.parse(x, { cli: true, expression: true });
         } catch(ex) {
             if (ex instanceof UglifyJS.JS_Parse_Error) {
                 print_error("Error parsing arguments for flag `" + flag + "': " + x);
diff --git a/lib/parse.js b/lib/parse.js
index 4d37b85..99d7ce0 100644
--- a/lib/parse.js
+++ b/lib/parse.js
@@ -695,6 +695,7 @@ function parse($TEXT, options) {
         html5_comments : true,
         bare_returns   : false,
         shebang        : true,
+        cli            : false,
     });

     var S = {
@@ -1501,6 +1502,7 @@ function parse($TEXT, options) {
     };

     function is_assignable(expr) {
+        if (options.cli) return true;
         return expr instanceof AST_PropAccess || expr instanceof AST_SymbolRef;
     };

$ echo 'console.log("👍  ok");' | bin/uglifyjs -b
console.log("👍  ok");



md5-4c97735e0f2a85495f00c6c12fe1076e



$ echo 'console.log("👍  ok");' | bin/uglifyjs -b ascii_only=true
console.log("\ud83d\udc4d  ok");



md5-4c97735e0f2a85495f00c6c12fe1076e



$ echo 'console.log("👍  ok");' | bin/uglifyjs -b ascii-only=true
console.log("\ud83d\udc4d  ok");

[kzc]

@alexlamsl In 3.x I think we should get rid of the misleadingly named parser option "strict" which is not related to "use strict".

[alexlamsl]

@kzc yeah, I think it's some sort of lint style thing than what's required inside a parser.