Skip to content

Omitted array option becomes [undefined] when an unrelated option is passed #175

Closed

Description

@edram

Issue Type

  • Bug Report
  • Feature Request
  • Other

Expected

An omitted array option with no default should remain absent. Passing an unrelated option should not change its value.

Actual

An omitted option configured with type: [] becomes [undefined] when another option is passed.

Save the following as examples/array-option.js in the CAC repository:

import { cac } from '../dist/index.js'

const cli = cac()
  .option('--type <type>', 'Choose a project type', {
    default: 'node',
  })
  .option('--externals <external>', 'Add externals', {
    type: [],
  })

console.log(cli.parse())

After installing dependencies, build CAC:

pnpm run build

Run without an explicit option:

node examples/array-option.js
{
  args: [],
  options: { '--': [], type: 'node' }
}

Then explicitly pass the same default value:

node examples/array-option.js --type node
{
  args: [],
  options: { '--': [], type: 'node', externals: [undefined] }
}

Neither invocation supplies --externals, but the second adds [undefined]. This makes an omitted option appear to contain one value.

Related: #36 introduced array type support. This report concerns omitted array options.

Possible Solutions

setByType runs after each explicitly parsed option is assigned and processes all registered array options, including those that are absent. For a missing option, [obj[key]].flat() produces [undefined].

Consider skipping absent options and applying transforms once after all parsed values have been assigned, while preserving explicit defaults.

I plan to submit a fix with regression tests for omitted array options, both with and without unrelated options.

Info

  • CAC version: 7.0.0 (local source checkout)
  • Commit: 165e613
  • Reproduction: Self-contained example above.

Activity

  1. changed the title [-]传入无关选项时,未提供的数组选项变为 `[undefined]`[/-] [+]Omitted array option becomes `[undefined]` when an unrelated option is passed[/+] on Sep 17, 2026
  2. added a commit that references this issue on Sep 17, 2026
    ce4aa80
  3. anselanza commented on Oct 9, 2026

    @anselanza

    Oof, +1 from me on this one.

    It just caused a big in production for me. Not fun filtering out [undefined] and then. checking .length > 0 just to have something default back to undefined as expected...

    Love the library! Hope you can merge this fix soon!

  4. edram commented on Oct 12, 2026

    @edram
    Author

    Hi @sxzz , I explicitly stated in #175 that I would submit a fix, and submitted #176 the same day. #177 was opened four days later to address the same issue. Could you clarify whether #176 was reviewed, and why #177 was selected instead? I haven’t received any feedback on my PR and would appreciate understanding the decision.

  5. sxzz commented on Oct 12, 2026

    @sxzz
    Member

    Hi @edram, sorry for the oversight. I saw #177 first in my GitHub notifications and missed #175 and your earlier PR #176. I reviewed #177, found no issues, and merged it without realizing you had already submitted a fix. I hadn’t reviewed #176 at that point, so this wasn’t a decision based on comparing the two PRs. Thank you for reporting the bug and taking the time to submit a fix, and sorry for leaving your PR without feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions