Open Richienb opened 2 years ago
Probably not, at least not right now. First of all, the API is experimental, but even after it becomes stable, it would be good to wait a few years to let it stabilize. Second, yarns-parser
has a lot of options and is more configurable.
I'll keep this open for discussion.
Second question would be:
Should
util.parseArgs
be used instead ofyargs-parser
when targeting Node.js 18?
The fact that Node.js decides to bundle a module doesn't make it automatically better than all the other modules, so I think one still would need to evaluate it against the alternatives.
If util.parseArgs
proves to be the better choice, then when Node.js 18 is the oldest supported LTS that could be a sensible choice to switch to.
Before that and one would need to po(n/l)yfill it
Update: parseArgs
now also available in Node.js 16. Still experimental.
Stand-alone package (ponyfill?) at https://github.com/pkgjs/parseargs but only one dependent on npmjs so far and not much interest expressed to date. Longterm maintenance not certain but is being actively maintained at the moment.
Second,
yargs-parser
has a lot of options and is more configurable.
Yes! By design, parseArgs
does not have much configuration. The "big switch" is strict: true
to throw for possible cli user error, or strict: false
to auto-detect options and leave it up to calling code to decide what to do.
👋 I have been absent from OSS these days, but wanted to provide my feedback (as the maintainer of yargs-parser
, and a contributor to util.parseArgs
).
I would love if util.parseArgs
could eventually be a replacement to yargs-parser
, I think to get there what would be needed would be a shim layer that fills in some of the missing behaviour (probably this shim layer would be a better replacement in meow than util.parseArgs
directly).
Could
util.parseArgs
be used instead ofyargs-parser
when targeting Node.js 18?