You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
@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:
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
This can be a great opportunity to set good examples/standards on how to use parseArgs on a real life cli application
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.
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. :-)
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.
Activity
dsanders11 commentedon Oct 21, 2022
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.RaisinTen commentedon Oct 21, 2022
Yea that makes sense to me. @ruyadorno do you have any other suggestions on this?
ruyadorno commentedon Oct 21, 2022
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:
postjectwithin Node.js, it would be great to use its native solution and avoid adding an extra bundled dependencyparseArgson a real life cli applicationpostjectto 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.jviotti commentedon Oct 21, 2022
As a big fan of reducing dependency scope, I'm +1 on the idea of ditching commander if it's doable.
RaisinTen commentedon Oct 22, 2022
@ruyadorno thanks for chiming in and also thank you for the great points!
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. :-)bakkot commentedon Dec 2, 2022
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.tony-go commentedon Dec 2, 2022
+1 for using native solution
sheplu commentedon Dec 2, 2022
+1 for using parseArgs
src: add parseArgs replacement for commander