no-command [...args] - first arg munged to number type

[rjharmon]

Issue Type

• Bug Report
• Feature Request
• Other

Reproduce by...

Define a "no command" command having only [...args]. vitest does this, for example.

User provides an arg such as 03, which for the vitest use case indicates "filter tests on the string 03".

> vitest 03

Expected

Consumers of each parsed arg should get the strings that were provided by the user

Actual

cac treats the first arg as a number if it can, though I can't see where it's forcing that. Later args aren't converted to numbers.

The consuming library then receives a list of args, the first of which is a number, and the others seem to always preserve stringiness. Then, downstream consumers of that data, looking for string capabilities like replace() trigger an error, based on a reasonable expectation that command-line args are strings.

TypeError: input.replace is not a function
    at normalizeWindowsPath (file:///[...]/node_modules/.pnpm/[email protected]/node_modules/pathe/dist/shared/pathe.ff20891b.mjs:6:16)
    at normalize (file:///[...]/node_modules/.pnpm/[email protected]/node_modules/pathe/dist/shared/pathe.ff20891b.mjs:19:10)
    at Array.map (<anonymous>)
    at start (file:///[...]/node_modules/.pnpm/[email protected]_@[email protected]/node_modules/vitest/dist/chunks/cac.DGgmCKmU.js:1499:52)

Note vitest's use of https://github.com/vitest-dev/vitest/blob/main/patches/cac%406.7.14.patch - doesn't seem to be a cause, but I am not an expert on it.

Possible Solutions

Speculation: use the literal string of an unmatched command, rather than a processed version of that string, when constructing the final [...args] list for the no-command case.

workaround: dependents on this lib offer a run [...args] or watch [...args], and make users figure out that they have to use it.

workaround: dependents on this lib avoid defining commands of this type.

Info

• CAC version: 6.7 14
• Reproduction link: vitest 03