Describe the user story
As a developer building tooling that invokes Yarn programmatically, I need to support multiple Yarn versions at once. Some command-line flags only exist in specific Yarn releases, which means a command that works on one version can fail on another with an Unsupported option name error.
This is also complicated by CI environments that inject global Yarn configuration via environment variables (e.g. YARN_NPM_*). These settings may be valid for some Yarn versions but can unexpectedly break others.
I would like a way for Yarn to ignore unknown command-line options instead of failing, so that tooling and CI integrations remain compatible across versions.
Example
yarn --version
4.9.2
export YARN_NPM_MINIMAL_AGE_GATE=0
yarn install
Usage Error: Unrecognized or legacy configuration settings found: npmMinimalAgeGate - run "yarn config -v" to see the list of settings supported in Yarn (in <environment>)
For this particular example, YARN_NPM_MINIMAL_AGE_GATE is no-op on 4.9.2 as the feature was not introduced yet so failing with that error provides very little value on my context.
Describe the solution you'd like
Add an opt-in flag such as --ignore-unknown-options that causes Yarn to skip unrecognized CLI arguments instead of erroring.
Example:
yarn --ignore-unknown-options add --some-future-flag react
Unknown flags would be ignored, while valid ones would still be processed normally.
Describe the drawbacks of your solution
Unknown flags are often the result of typos, so ignoring them could hide real user errors and make debugging harder.
It also introduces ambiguity in behavior, since a command may behave differently depending on which flags are silently ignored. That said, passing --ignore-unknown-options would be a deliberate choice and risk that users would accept
Describe alternatives you've considered
A common workaround is to branch logic based on Yarn version and only pass supported flags. While this works, it is brittle and risky: it requires maintaining version compatibility mappings and can break when new Yarn versions are introduced or detected incorrectly.
Another option is to retry commands after failure, stripping unsupported flags based on error output, but this is also fragile and adds complexity.
CI-driven configuration via YARN_NPM_* environment variables can also conflict across versions, making version-aware logic even harder to maintain reliably.
A plugin-based solution is not sufficient because CLI parsing happens before plugins can intervene.
Describe the user story
As a developer building tooling that invokes Yarn programmatically, I need to support multiple Yarn versions at once. Some command-line flags only exist in specific Yarn releases, which means a command that works on one version can fail on another with an
Unsupported option nameerror.This is also complicated by CI environments that inject global Yarn configuration via environment variables (e.g.
YARN_NPM_*). These settings may be valid for some Yarn versions but can unexpectedly break others.I would like a way for Yarn to ignore unknown command-line options instead of failing, so that tooling and CI integrations remain compatible across versions.
Example
For this particular example,
YARN_NPM_MINIMAL_AGE_GATEis no-op on4.9.2as the feature was not introduced yet so failing with that error provides very little value on my context.Describe the solution you'd like
Add an opt-in flag such as
--ignore-unknown-optionsthat causes Yarn to skip unrecognized CLI arguments instead of erroring.Example:
Unknown flags would be ignored, while valid ones would still be processed normally.
Describe the drawbacks of your solution
Unknown flags are often the result of typos, so ignoring them could hide real user errors and make debugging harder.
It also introduces ambiguity in behavior, since a command may behave differently depending on which flags are silently ignored. That said, passing
--ignore-unknown-optionswould be a deliberate choice and risk that users would acceptDescribe alternatives you've considered
A common workaround is to branch logic based on Yarn version and only pass supported flags. While this works, it is brittle and risky: it requires maintaining version compatibility mappings and can break when new Yarn versions are introduced or detected incorrectly.
Another option is to retry commands after failure, stripping unsupported flags based on error output, but this is also fragile and adds complexity.
CI-driven configuration via
YARN_NPM_*environment variables can also conflict across versions, making version-aware logic even harder to maintain reliably.A plugin-based solution is not sufficient because CLI parsing happens before plugins can intervene.