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/pathe@1.1.2/node_modules/pathe/dist/shared/pathe.ff20891b.mjs:6:16)
at normalize (file:///[...]/node_modules/.pnpm/pathe@1.1.2/node_modules/pathe/dist/shared/pathe.ff20891b.mjs:19:10)
at Array.map (<anonymous>)
at start (file:///[...]/node_modules/.pnpm/vitest@2.0.5_@types+node@20.12.12/node_modules/vitest/dist/chunks/cac.DGgmCKmU.js:1499:52)
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.
Issue Type
Reproduce by...
Define a "no command" command having only
[...args].vitestdoes this, for example.User provides an arg such as
03, which for thevitestuse case indicates "filter tests on the string 03".> vitest 03Expected
Consumers of each parsed arg should get the strings that were provided by the user
Actual
cactreats 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.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]orwatch [...args], and make users figure out that they have to use it.workaround: dependents on this lib avoid defining commands of this type.
Info
vitest 03