I ended up settling for it as well (I couldn't find anything better, nor make it break) but I'd be really surprised if it was the way to go
Like `node --enable-tracing script.js --name=John --age 30 --verbose`
This works because node seems to hide --enable-tracing to the underlying script
But would it work with Bun & Deno...? Is that standard...?
It didn't account for the presence of a '--' to end the parsing of named arguments but that's it
That’s just something getopt does and some programs adopted. If you asked me to write a parser, I wouldn’t necessarily include that either if you didn’t ask for it.
Some positional arguments can be filenames, filenames can be --help and --verbose or --name=Frank
You have to have `--` or something similar to have a correct program
No, only if the positional arguments need to support arbitrary strings. If you have something like a package manager and the first positional argument is the subcommand and everything after is an alphanumeric package name, you don’t need to support the double dash.
Package managers is an especially bad example because github projects typically are github.com/author-name/words-separated-by-dashes
So you will probably have somebody along the way pester you about allowing dashes between words, to play nice with github
But who's to know if the guy making that change will think of disallowing dashes at the start of the words? Likely he'll just add \- to /[A-Z\-]+/
Suddenly the script you wrote starts getting passed positional arguments that have dashes in them, until some wise guy tries to create a package called `--verbose`, then notices unintended effects on your pages, goes ahead trying `--verbose -- react`, ...
So anyway -- if I'm making a heavily reusable piece of code like this I make it as general purpose as possible in a way that makes it impossible to mis-use it