feat!: remove allowArbitraryFlags parse override

[eablack]

Summary

Removes the Command.parse() override gated behind allowArbitraryFlags, the allowArbitraryFlags instance property, the now-unused CLIError import, and the yargs-parser / yargs-unparser (+ @types) dependencies that only it used.

The override existed solely to rescue a long-deprecated input style for heroku addons:create — passing arbitrary add-on config flags without the -- end-of-options separator (deprecated in changelog item 2925). The supported -- syntax does not depend on this code: with static strict = false, tokens after -- already flow into argv for the command to read via its own parseConfig().

It was also fragile and untested in this library: it round-tripped argv through yargs-parser → yargs-unparser, which coerces types (e.g. 1.20 → 1.2, --flag=false → --no-flag) and mangles flag names (camelCase/dot/short-flag expansion).

A sweep of all local Heroku repos and bundled plugins found exactly one consumer: heroku/cli's addons:create.

Type of Change

Breaking Changes (major semver update)

• Add a ! after your change type to denote a change that breaks current behavior

feat! — Command#allowArbitraryFlags and the result.nonExistentFlags field it produced are removed from the published type. Commands that passed arbitrary flags without a -- separator must now use the -- end-of-options separator.

Important

Coordinated change required. heroku/cli's addons:create must be updated in the same release to stop setting allowArbitraryFlags and reading nonExistentFlags, and to drop its deprecated-syntax test case. Its existing parseConfig(argv) already handles the supported -- tokens, so command behavior is unchanged. This PR targets the v14.0.0 branch (unreleased).

Testing

Notes: This is a library change with no runnable command of its own, so manual verification is done through its one consumer, heroku/cli's addons:create. Link this branch into a local heroku/cli checkout first:

# in this repo (heroku-cli-command), on this branch
npm run build
npm link                        # registers a global link to this build

# in your local ~/workspace/cli checkout
npm link @heroku-cli/command    # points cli's dependency at the linked build
npm run build

Then run the commands below from the cli checkout with ./bin/run.js.

Steps:

1. Supported -- syntax still passes config through — run against an app you control:
   ./bin/run.js addons:create heroku-postgresql:essential-0 -a <your-app> -- --fork <SOURCE_DB_URL_OR_NAME>
   → the add-on provisions and the --fork config reaches the provider; no parse error and no deprecation warning.
2. Deprecated no-separator syntax now errors (the intended breaking change) — same command without --:
   ./bin/run.js addons:create heroku-postgresql:essential-0 -a <your-app> --fork <SOURCE_DB_URL_OR_NAME>
   → the CLI now exits with a Nonexistent flag: --fork error, instead of the old "deprecated syntax" warning + silently working. (This error happens before any API call, so no add-on is created.)
3. No regression for a plain create — ./bin/run.js addons:create heroku-redis:mini -a <your-app> provisions normally.

Note: because heroku/cli's addons:create isn't updated yet (see the coordinated-change callout above), the local cli checkout for this test should be at a commit before that update — otherwise addons:create will no longer compile against the removed API. The point of the test is to confirm the supported -- path is unaffected by removing the override.

CI also runs the full lint/build/unit suite on this branch.

Related Issues

GitHub issue: N/A
GUS work item: W-24461070

[tlowrimore-heroku]

LGTM!