docs: add util.parseArgs replacements for CLI argument parsers

[bjnewman]

Summary

Adds migration documentation for replacing CLI argument parsing packages with Node.js built-in util.parseArgs (available in Node 18.3+/16.17+).

Packages covered

• minimist
• mri
• arg
• meow
• yargs-parser
• yargs
• commander
• sade

Changes

• New docs/modules/parseargs.md with migration examples for each package
• Added 8 entries to manifests/preferred.json

Notes

• Examples use nullish coalescing (??) for defaults instead of parseArgs's default option to ensure compatibility with all Node 18.3+ versions
• Includes feature comparison table and caveats about subcommands/auto-help
• Covers advanced patterns like token-based parsing for minimist compatibility

[ljharb]

Also worth suggesting as an alternative is https://npmgraph.js.org/?q=pargs, which is built on top of util.parseArgs, has no deps, is written in ESM, and adds a number of helpful features when migrating from the listed packages.

[43081j]

sorry its taken me a while to get to this

i think we need some 2nd opinions here as this diverges from the usual structure we have

we follow one of two paths so far:

• the document is named after the thing being replaced, and lists migrations to the various options
• the document is named after the primary replacement (e.g. fetch), and lists other options but usually no migrations

in this case, it is listing the things being replaced along with their migrations. which is different to all other docs

@Fuzzyma thoughts?

[Fuzzyma]

hm, so would you rather have x documents that all have one migration "x to fetch" and then in the fetch document link to all migrations? I think that would be cumbersome.

Is there a reason we usually dont have migrations in the "fetch-like" documents?

[bjnewman]

Thanks for the great work on this project and for taking the time to
review! I went with a single doc covering all 8 packages because their
APIs all converge on the same built-in replacement (util.parseArgs),
and I wanted to show the specific before/after for each since they have
pretty different APIs.

I was loosely modeling off of fetch.md, lodash-underscore.md, and
bluebird-q.md, which also group multiple packages into one doc. But I
can see how the per-package migration examples diverge from those.

Happy to restructure to better fit the project — just let me know what
you'd prefer and I'll update.

[43081j]

i more meant that the way fetch.md is structured is fine, but this isn't structured like that

im finding it difficult to find the right words to explain this 😂

the fetch document explains fetch and alternative packages.

this document explains packages being replaced.

i.e. the focus/context in the fetch doc is the alternatives, but the focus in this one is the replaced modules.

EDIT:

like the title of the page is # Replacements for argument parsers, but then we list the packages being replaced (the headings are those of the packages being replaced). everywhere else, we list the replacements (as per the title)