Wording for flagged as "documented": more performant alternatives

[shadowspawn]

The npmx.dev commander page says:

You might not need this dependency.
This package has been flagged as having more performant alternatives.

The "more performant" suggests to me that there are objectively better alternatives suggested, likely smaller and faster. But the reasons for "preferred replacements" are much more varied and are opinionated.

I suggest it would be more accurate to leave out the "more performant" from the generic text. If that is a bit too dry, perhaps "This package has been flagged as having alternatives to consider.", or reflecting the source of the recommendations "This package has been flagged as having preferred alternatives.".

From e18e/module-replacements:

This is a very opinionated list of modules with preferred replacements. Often these replacements are much lighter or more modern than the modules they are replacing.

Sometimes these may also be actively maintained forks of older, unmaintained source packages.

Additional notes:

• Disclaimer: I am a maintainer of commander, so not a neutral observer.
• The "more performant alternatives" wording was added in feat: add module-replacements support first class #268
• Current wording source:

  npmx.dev/i18n/locales/en.json

  Line 439 in e731a54

  "documented": "This package has been flagged as having more performant alternatives.",

• I first opened Flagged: more performant alternatives #2995, but reworked that to focus on just the wording here in npmx.dev. Moved the replacements discussion to Commander e18e/module-replacements#772

[43081j]

This isn't quite true. The "more performant" wording is correct and you just happen to have chosen the one case where we should discuss if its meant to be in there or not.

The correct thing to do here is to open an issue in module-replacements about cleye being in there - not to change the wording here (and everywhere else that uses this wording...).

The reasons for preferred replacements are absolutely because they're more performant. If you think you've found one where that isn't true, it deserves an issue, basically.

In future, we do want to expand this reasoning to "security and performance" but we haven't done that yet. When we do, npmx and the various other tools using this data set will probably say something more like "more performant and/or secure alternatives".

[shadowspawn]

Oh! Thanks for explanation. I hadn't seriously considered that outcome. (I went in wrong direction trying to make what I saw self-consistent.)

On a related note, nice to see distinction between "Replacements for argument parsers" and "Replacements for CLI builders".

[43081j]

its a living data set too so things change. we have to add and remove entries as packages change.

i think you're probably right and that cleye should be removed until it drops the CJS entrypoint (so it stops being a dual-package).

On a related note, nice to see distinction between "Replacements for argument parsers" and "Replacements for CLI builders".

yup often the bloat comes from trying to handle both of those categories in one package 😄 many consumers only need one, not both (especially with parseArgs being a thing).