Replace `commander` with `parseArgs` about postject

[ruyadorno]

thanks @RaisinTen for bringing this up!

@dsanders11 I agree 100% with your initial statement, the goal of the native parseArgs module was never to replace full blown cli frameworks such as commander.

That said, my proposal to use it here instead is based on different types of motivations:

1. Given the intention to vendor postject within Node.js, it would be great to use its native solution and avoid adding an extra bundled dependency
2. This can be a great opportunity to set good examples/standards on how to use parseArgs on a real life cli application
3. By moving postject to the Node.js org, more contributors will be attracted to the project, which can help ease the extra work load, also these contributors might be more familiar with the standard parseArgs module than a specific cli framework (myself included)

Outside of these practical reasons, there are also the relevance of helping creating more synergy between the collaborators of postject and the larger pool of Node.js collaborators. I'd encourage the team here to report and even propose improvements to the parseArgs module moving forward. Also relevant to this point, did you know parseArgs is the result of a lot of collaboration between the maintainers of both commander and yargs that originally took place at https://github.com/pkgjs/parseargs as part of a Node.js Tooling Group initiative? 😊 A big motivation of my initial idea was helping promote this type of collaborative work!

With all that in mind I totally respect your call on this. Just let me know in case you want to move forward with parseArgs since I might be able to contribute a little to the this specific initiative and also help rally more folks from the Working Groups that might be willing to help with the work necessary.

[dsanders11]

I don't think parseArgs is a replacement for commander in Postject, it's too minimal. For example, we'd lose the whole help functionality and usage output we currently have. It would also make #43 more trickier, while commander provides sub-command functionality.

[RaisinTen]

Yea that makes sense to me. @ruyadorno do you have any other suggestions on this?

[jviotti]

As a big fan of reducing dependency scope, I'm +1 on the idea of ditching commander if it's doable.

[RaisinTen]

@ruyadorno thanks for chiming in and also thank you for the great points!

Given the intention to vendor postject within Node.js, it would be great to use its native solution and avoid adding an extra bundled dependency

The way I initially imagined node would use postject is through the programmatic API here - https://github.com/postmanlabs/postject/blob/b9356bf75ba4c22aab6baeaab51a94111ef4a79b/src/api.js#L6, i.e., the inject() function. This file does not do require('commander'), so commander would not be a part of the bundled JS file that was being used inside node.

However, I agree with the rest of the points you raised and I'm fully supportive of using parseArgs if possible without adding a lot of complexity. :-)

[bakkot]

It would also make #43 more trickier, while commander provides sub-command functionality.

Incidentally if you do go for this, subcommands are doable in parseArgs with a relatively small amount of boilerplate. More work than commander, but not that bad.

[tony-go]

+1 for using native solution

[sheplu]

+1 for using parseArgs