Replace minimist with parseArgs from node:util

[ChristianMurphy]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Problem

minimist is an additional dependency which needs to be downloaded.

Solution

Node now provides parseArgs as part of node:util, with a similar functionality and API.
It has been made available as far back as Node 16 https://nodejs.org/dist/latest-v16.x/docs/api/util.html#util_util_parseargs_config

Alternatives

continue using a user land argument parser.

[remcohaszing]

parseArgs is great, but it is also experimental.

@pkgjs/parseargs is a nice polyfill.

[wooorm]

nodejs/node#46718

[wooorm]

What does it mean if something is stable on Node 20 but experimental on Node 16/lts and 18/lts? 😅
I guess we can use it then, right?

[remcohaszing]

I guess we can use it then, right?

IMO yes

[ChristianMurphy]

I guess we can use it then, right?

I'd lean Yes as well.

[wooorm]

Spent a couple hours investigating. It’s not really bad. But it isn’t an improvement at all. It doesn’t lead to less code. I think one very important thing we currently have is negation: some stuff is default on, but with --no it is negated, so like --no-color. That doesn’t normally work. you can make it work when getting tokens back and with a bunch of extra.
Second is that it doesn’t have good errors. We currently have good errors. I’d need to regex Node’s errors to figure out which flags were incorrectly passed, parse them, and then figure out an improved error message.
Then, it doesn’t support things that can be both booleans and strings (our output).
Last, it handles combined short flags such as -on as -o n (--output n), because it doesn‘t accept it as a boolean, whereas we’d like to.

It’s not an improvement. It’s either a bare bones opinionated parser that throws programming exceptions if things are wrong, or it’s just a tokenizer.
For it to be useful, it would have to have a bunch more options, to make it smarter.

So perhaps in a couple years.

[remcohaszing]

To be fair I always found the behaviour of -o a bit quirky. If remark . -o works, I expect remark -o . to work the same. In fact, I tend to run most CLIs with some-cli --options --go --first then positional arguments. I would rather have two options:

  -f  --fix                 overwrite input files
  -o  --output <path>       specify output location

[wooorm]

Oh, wait. What? How’s that quirky? Seems normal to me. There are tons of CLIs where your expectation doesn‘t work

[wooorm]

--fix is a name that implies things that are currently not yet done. Having it be syntax sugar for --output . seems, to me, as not much of an improvement?

[remcohaszing]

I can’t really think of CLIs with similar behaviour that surprised me. I think the fact that this behaviour can’t be expressed with parseArgs, but neither with for example Python’s builtin argparse and I think bash’s getopts, shows that this behaviour is a bit unconventional.

Indeed --fix would be an alias for --output .. Likewise, putting --output after positional arguments or before another option makes it an alias for --output ..

Given this is command

remark -q -o . .

These do the same

remark -o . -q .
remark -o -q .
remark -q . -o
remark . -qo
remark . -oq
remark -oq .

But these behave differently

remark -q -o .
remark -qo .
remark -o . -q

For similar options ESLint and Stylelint use --fix. Prettier uses --write.

Alternatively --output could treat the input path as the output if no input is given.

[wooorm]

This new post seems different from your earlier statement “If remark . -o works, I expect remark -o . to work the same.” That sounds like you want to throw on remark . -o, because from what I understand you don’t want to throw on remark -o .? 🤔 I don’t understand what you’re proposing, or what you’re trying to replace it other languages/tools?

[ChristianMurphy]

Closing this as stalled