Commander

Short version: does "performant" mean some particular measures of performance when a package is flagged with "This package has been flagged as having more performant alternatives" on npmx.dev? ----- Long version. Disclaimer: I am a maintainer of `commander`, so not a neutral observer. I noticed the [commander page](https://npmx.dev/package/commander) says: ``` You might not need this dependency. This package has been flagged as having more performant alternatives. ``` There are LOTS of command line parsers with varying performance and feature sets, each with happy users. I am interested in the alternatives, and also whether there is something I can improve in Commander without compromising the developer experience or functionality. The [Replacements for CLI builders](https://e18e.dev/docs/replacements/cli-builders) does not give any reason why the alternatives are being suggested. I think "performant" sounds like an objective measure of better. I expected the alternatives would be smaller and faster. Which seemed likely since Commander has accumulated lots of features. I nerd-sniped myself and have been doing some testing and measurements. (Able to publish workings and detail about the comparisons. Interested whether I am measuring things that people care about.) Package footprint on disk. Simple project with single direct dependency to package. | package | version | node_modules | total packages | | ------- | ------- | -----------: | -------------: | | (node:util) | 24.18.0 | 0 K | 0 | | sade | 1.8.1 | 80 K | 2 | | commander | 15.0.0 | 236 K | 1 | | cleye | 2.6.0 | 248 K | 3 | Note: I don't think package size is critical for a CLI library. And there are multiple tradeoffs between these packages. `sade` and `cleye` currently ship dual esm/cjs but also minify their code. Commander is esm-only but does not minify code. The full code offers a better developer experience when debugging or exceptions, if needed. Total time to run a simple program which parses command line arguments, effectively`node my-tool.mjs -b --value VALUE ARGUMENT`. (Measured using `hyperfine`.) | package | version | time | | ------- | ------- | ---------- | | sade | 1.8.1 | 30.0 ms ± 0.9 ms | | node:util | 24.18.0 | 30.6 ms ± 1.0 ms | | commander | 15.0.0 | 37.7 ms ± 1.0 ms | | cleye | 2.6.0 | 43.5 ms ± 1.2 ms | So `cleye` is "bigger" and "slower" than `commander`!? (For some definition of "bigger" and "slower"...) I later found this repo has explanation for Preferred replacements in README: > 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. An improvement might be to give a clue why the packages are on the "Replacements for CLI builders" page. Speculation on reasoning: the suggested packages cover the commonly used features. Sade is small and fast. Cleye has built-in TypeScript type inference for the parse results. The "performant" wording on npmx.dev does not sound "very opinionated". References: - "Replacements for CLI builders" added in https://github.com/e18e/module-replacements/pull/528 - Some discussion in first cut for alternatives for parsers in #274 - The "performant alternatives" wording in npmx.dev was added in [#268.](https://github.com/npmx-dev/npmx.dev/pull/268)