Design does not make it possible to process ordered flags

[KernelDeimos]

Many POSIX coreutils have ordered flags. For example the ls command is able to perform multiple sorts, and the order of these sorts is determined by what order to provide the flags in.

I'm not sure whether or not this will be considered out of scope for minimist, but I think it's worth pointing out and discussing because this module is used by popular packages like vorpal and has potentially had a lot of influence on how CLI argument processing is done across node.js packages.

The function would need to return an array instead of an object for this to work, so it would have to be an opt-in in the options object. I'm going to implement this either way so if I get the green light on this issue I'll contribute it here.

[ljharb]

Does the order of the options not currently match the order arguments are found?

[shadowspawn]

I think ordered flags is unusual. Although I concede some commands may want to do this!

The POSIX Utility Syntax Guidelines say:

Guideline 11: The order of different options relative to one another should not matter, unless the options are documented as mutually-exclusive and such an option is documented to override any incompatible options preceding it. If an option that has option-arguments is repeated, the option and option-argument combinations should be interpreted in the order specified on the command line.

[KernelDeimos]

Does the order of the options not currently match the order arguments are found?

Sometimes this is sufficient, but with complicated nuances. In some POSIX utilities (this includes rm and ls, which are just the ones I've deeply looked into so potentially a lot of the coreutils) flags can actually appear more than once and this affects the behavior as well.

• In rm the order of the last occurrences of -f and -i matters,
• In ls the different sortings flags (-S, -t, etc) can be ordered for different results; -r reverses the last sort performed no matter where it appears. I think relying on object key order actually does work for this case.

[shadowspawn]

Aside from repeated options, the other case that is not covered by property order is boolean options which are created before parsing.

import parse from 'minimist';
console.log(parse(process.argv.slice(2), { boolean: ['b'] }));

% node index.mjs            
{ _: [], b: false }
% node index.mjs -z -y -b -x
{ _: [], b: true, z: true, y: true, x: true }

[shadowspawn]

For interest, ordered flags is a use case that was considered for parseArgs in https://github.com/pkgjs/parseargs/issues/84 and ultimately shipped as tokens: https://nodejs.org/docs/latest/api/util.html#parseargs-tokens

[ljharb]

Adding something like tokens seems fine, and an option wouldn't be required.