Is `strict` actually a goal?

[shadowspawn]

strict {Boolean} (Optional) A Boolean on wheather or not to throw an error when unknown args are encountered

The current interface is leaning towards the minimal (magic) configuration goal of the original proposal. I do not currently see a way of declaring an option as being known but not taking a value, so there is no way to identify unknown options?

The FAQ includes:

Do unknown arguments raise an error? Are they parsed? Are they treated as positional arguments?
no, they are parsed, not treated as positionals

Related:

• Default Behavior: Boolean Flags in util: add util.parseArgs() nodejs/node#35015 (comment)
• util: add util.parseArgs() nodejs/node#35015 (comment)
• util: add util.parseArgs() nodejs/node#35015 (comment)
• util: add util.parseArgs() nodejs/node#35015 (comment)

(A different case is --foo=bar when foo is not specified to take an argument value. Not including that as part of strict for current question. nodejs/node#35015 (comment))

[ljharb]

It should be a goal to error and show help output when an unknown argument is passed, just like when a known argument is passed with an incorrect value.

[darcyclarke]

@ljharb

"It should be a goal to error and show help output when an unknown argument is passed"

Agree.

"just like when a known argument is passed with an incorrect value."

Disagree. Also, a bit confused; I don't see any way the current spec allows you to define a value which validates against a value passed. The goal of this spec, which differentiated it from the previous work, was that you'd "bring your own validation" in reference to values & types.

@shadowspawn the F.A.Q. is fairly conversational in nature (as it literally spawned out of a discussion between myself & @isaacs); with that in mind, it's correct in stating that we should parse (to the best of our abilities & with the options provided) all input. strict mode should throw an error when args are found that aren't explicitly defined/"known" in withValues (or... maybe some other option which isn't spec'd yet?)

[darcyclarke]

(A different case is --foo=bar when foo is not specified to take an argument value. Not including that as part of strict for current question. nodejs/node#35015 (comment))

This makes sense... I'm actually a +1 to just kill strict for now. End-user can decide to throw if they see a flag they weren't expecting.

[ljharb]

@darcyclarke i meant conceptually - obviously this package wouldn't provide validation, but what's the use case for anyone wanting to permit unknown values?

[darcyclarke]

@ljharb I know of usecases, today, where you'd want to capture unknown/undefined flags (to the root program) & pass those along to another process or use in some form later (ex. npm's support of infinite config 👀 🤦🏻). Not saying it's a best practice, just that usecases exist.

Contrived Example:

node mkdir.js ./path/to/new/dir/ --force --verbose --parents

// mkdir.js

const knownOpts = ['force']
const { flags, positionals } = parseArgs({ withValue: knownOpts })
const args = Object.keys(flags).filter(f => knownOpts[f])
const cmd = (flags.force) ? 'sudo mkdir' : 'mkdir'

process('child_process').spawnSync(cmd, [...args, ...positionals])

In the above, I expect & am aware of --force but all other flags & positionals get passed along to a child process (note: mkdir will then throw if it's not aware of those).

[ljharb]

Must we support every possible use case? Or perhaps it’d be better to establish good defaults, since nobody is forced to use this solution, and it’s perfectly fine if not everyone can.

[bcoe]

Are we okay with dropping strict behavior for MVP? we can change this decision depending on code review on Node.js.

[ljharb]

I'm still not sure why anyone would want non-strict - it seems much better to be strict by default, and let developers opt in to allowing unknown arguments.

[shadowspawn]

Reference, two of the summary message from previous thread covering strictness and correctness:

• util: add util.parseArgs() nodejs/node#35015 (comment)
• util: add util.parseArgs() nodejs/node#35015 (comment)

[shadowspawn]

Short version: I am ok with wrapping a release without strict detection of unknown arguments. But I am willing to invest in strict mode for the misuse errors in first instance, and then for unknowns.

Long version

A big part of the original vision is the minimal config. This is incompatible with strict since flags are discovered at runtime and can't be "unknown", typos can not be detected by the parser.

I think the minimal config is appealing and useful for quick programs used mainly by their own author. I am reassured that @bcoe thinks the non-strict mode is useful with his experience with Yargs and support issues.

To make parseArgs useful to a wider audience, I think strict is important. This expands the audience to safer usage where the author can rely on common errors being detected and handled without writing their own code, and the end-user can rely on the program blocking many cases of accidental misuse. I want the utilities I write to become strict as they mature.

I don't feel it is worth silently returning an error message when not strict. (This idea is raised in a few places in the context of strict, and idea that parsing always succeeds.) I think that once an error has been detected then the parsing is tainted. So strict is a yes/no mode, the strict parse succeeded or it failed, and an exception is appropriate.

I suggest as a proof of concept we implement strict to throw for the error cases for a flag used with a value, and withValue option used without a value. These are within the scope of what is already described in the README and encountered in the current code and discussed at length in open issues. This is not what the README describes strict as for, but I feel it is within the spirit!

(As an aside, I continue to be impressed by how flexible Minimist is. Looks like is is capable of implementing strict for unknown arguments by using opts.unknown and declaring the expected options.)

[ljharb]

I’ve used yargs in a half dozen projects, and always ended up adding strict later. Without strict, adding any argument is a breaking change. Strict mode is the only way semver-minor becomes practical.

[bcoe]

I’ve used yargs in a half dozen projects, and always ended up adding strict later.
I suggest as a proof of concept we implement strict to throw for the error cases for a flag used with a value, and withValue

I'm convinced we should have strict for MVP, but I'd make the case for it being an opt in, as with yargs.

Would you be okay with this compromise @ljharb (needing to set a strict: true in the options).

[ljharb]

@bcoe can you actually make the case? in what use case or realm of computing is non-strict a desired default?