Repository navigation
Replace commander with parseArgs #56
Description
Activity
I don't think
parseArgsis a replacement forcommanderin 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, whilecommanderprovides sub-command functionality.Yea that makes sense to me. @ruyadorno do you have any other suggestions on this?
thanks @RaisinTen for bringing this up!
@dsanders11 I agree 100% with your initial statement, the goal of the native
parseArgsmodule was never to replace full blown cli frameworks such ascommander.That said, my proposal to use it here instead is based on different types of motivations:
- Given the intention to vendor
postjectwithin Node.js, it would be great to use its native solution and avoid adding an extra bundled dependency - This can be a great opportunity to set good examples/standards on how to use
parseArgson a real life cli application - By moving
postjectto 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 standardparseArgsmodule 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
postjectand the larger pool of Node.js collaborators. I'd encourage the team here to report and even propose improvements to theparseArgsmodule moving forward. Also relevant to this point, did you knowparseArgsis the result of a lot of collaboration between the maintainers of bothcommanderandyargsthat 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
parseArgssince 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.Reacted by Darshan Sen and Tony Gorez- Given the intention to vendor
As a big fan of reducing dependency scope, I'm +1 on the idea of ditching commander if it's doable.
@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
parseArgsif possible without adding a lot of complexity. :-)It would also make #43 more trickier, while
commanderprovides sub-command functionality.Incidentally if you do go for this, subcommands are doable in
parseArgswith a relatively small amount of boilerplate. More work thancommander, but not that bad.+1 for using native solution
+1 for using parseArgs
- added a commit that references this issue
on Dec 18, 2022 - linked a pull request that will close this issuerefactor: replace commander with parseArgs #67
on Dec 19, 2022
See nodejs/node#45038 (comment)