Upgrade outdated dependency to commander

[guimard]

wishlist

Uglify version (uglifyjs -V) ≥ 2.8.29

Hi,

here is a simple patch that permits to use uglifyjs without behavior change with commander > 4 (tests succeeds). Change that affects uglifyjs is explained here.

• option with optional argument : replace -cme by -c -m -e (else it becomes -c me)

--- a/bin/uglifyjs
+++ b/bin/uglifyjs
@@ -5,6 +5,15 @@

 require("../tools/exit");

+var argv = [];
+process.argv.forEach(function(arg){
+  if(arg.match(/^-([cebmo]+)$/)) {
+    argv = argv.concat(RegExp.$1.split('').map(s => { return '-'+s }));
+  }
+  else argv.push(arg);
+});
+process.argv = argv;
+
 var fs = require("fs");
 var info = require("../package.json");
 var path = require("path");

• --rename default value (change order) :

--- a/bin/uglifyjs
+++ b/bin/uglifyjs
@@ -44,8 +53,8 @@
 program.option("--ie8", "Support non-standard Internet Explorer 8.");
 program.option("--keep-fnames", "Do not mangle/drop function names. Useful for code relying on Function.prototype.name.");
 program.option("--name-cache <file>", "File to hold mangled name mappings.");
-program.option("--rename", "Force symbol expansion.");
 program.option("--no-rename", "Disable symbol expansion.");
+program.option("--rename", "Force symbol expansion.");
 program.option("--self", "Build UglifyJS as a library (implies --wrap UglifyJS)");
 program.option("--source-map [options]", "Enable source map/specify source map options.", parse_js());
 program.option("--timings", "Display operations run time on STDERR.");

[alexlamsl]

Thanks for the suggestion, though there is a different reason why we decided to stay on the 2.x series.

But if we do need to upgrade in the future, your patch would come in handy 👍

[jonassmedegaard]

@alexlamsl could you elaborate/reference the reasoning for staying with the 2.x series?

Reason I ask is that Debian currently carries only one version of the commander module (to limit what the distribution need to care about), and we now consider moving to 4.x but perhaps you have some insight as to why we maybe shouldn't - or why we perhaps should consider maintaining 2 versions concurrently.

[jonassmedegaard]

ah, I guess the reason is compatibility with Nodejs v0.10 as indicated in #3450 - we do not have that need for Debian, but I admire your strong focus on backwards compatibity!

Please do share if you are aware of other reasons to stay with commander v2.0.

[alexlamsl]

Yes that is indeed the reason − at some point we could internalise the command line functionality (just as we did for source-map) since we use a very limited subset of what commander provides. Would that alleviate your concern?

[jonassmedegaard]

Quoting Alex Lam S.L. (2020-06-05 12:53:51)

Yes that is indeed the reason − at some point we could internalise the command line functionality (just as we did for `source-map`) since we use a very limited subset of what `commander` provides. Would that alleviate your concern?

It would indeed - that would be an improvement. Thanks!