`required` option

[Semigradsky]

Currently, Node.js is checking that arg has the correct type (by the strict option).
By I need manually check that this arg was provided by user. How about boolean flag required for this?

Before:

const { values } = parseArgs({
  options: {
    param: { type: 'string', short: 'p' },
  },
})

if (!values.param) {
  console.error('The "--param" param is required!')
  process.exit(1)
}

After:

const { values } = parseArgs({
  options: {
    param: { type: 'string', short: 'p', required: true },
  },
})

[Eomm]

I think we should define the following:

• do we want to list all the missing required params? (I think it would be useful)
• should a required: true, default: foo option be rejected? (In this case, the required field should be ignored)
• we can't have an empty array right now, so it should not be a use case to manage

---

I would like to share this interesting discussion from the JSON Schema spec, that adopted the pattern:

const { values } = parseArgs({
  required: [ 'param' ]
  options: {
    param: { type: 'string', short: 'p' },
  },
})

json-schema-org/json-schema-spec#846

[bakkot]

See some discussion at nodejs/node#44564 / nodejs/node#44565.

Personally I agree with the argument against doing this made in this comment.

[shadowspawn]

required functionality is a reasonable suggestion, but I personally don't think it is clean enough and compelling enough to add. --help and --version from the linked comment are good examples of complications.

---

Side note on potential naming confusion. The terms "required" and "optional" also get used to describe whether an option must have an option value. Given these three uses:

my-util
my-util --param
my-util --param VALUE

parseArgs does not currently allow the middle one (when strict) because type: 'string' means an option-value is required when the option is used. So I might think required: false would allow that case.

A possible name to reduce this confusion is requiredOption, for when the option must be supplied by the end user.

(Edit: for interest, yargs has demandOption and requiresArg.)

---

should a required: true, default: foo option be rejected?

That is simple to understand. I took a different approach when implementing required-option functionality myself, in case the author was using the default as simple support for environment variables. This does makes the behaviour of required-option more subtle, it means the option must have a value after parsing, rather than requiring it is specified on command-line.

  options: {
    password: { type: 'string', requiredOption: true, default: process.env.PASSWORD },
  },