Problem
Almost every option of check has a twin setter in Config, so the same setting can be expressed in two places. But some of these settings are properties of the project — they never legitimately change from one invocation to the next. For those, the CLI option is a liability: teams end up repeating them in every CI script instead of setting them once in the versioned config file, and two sources of truth invite drift.
Guiding principle
phparkitect.php is the project's source of truth. The CLI exists for bootstrap (where to find things) and for one-off overrides of a single run. The test for each option: is there a legitimate reason for this setting to vary between invocations? If not, it doesn't belong on the CLI.
Classification
| Category |
Options |
Fate |
| Bootstrap (must be CLI) |
--config, --autoload |
Keep |
| Runtime / one-off override |
--stop-on-failure, --format, --skip-baseline |
Keep (CLI overrides config) |
| Project property |
--target-php-version, --ignore-baseline-linenumbers, --use-baseline |
Config only — drop the CLI option |
Note on --target-php-version: it may look like a candidate for CI overrides (multi-PHP matrix), but it isn't — architectural rules are checked against one PHP version, the minimum the project supports. That's a property of the project, full stop.
The Config setters for the "project property" rows already exist (targetPhpVersion(), ignoreBaselineLinenumbers(), baselineFilePath()), so removing an option is just dropping the flag and documenting the setter.
Migration: fail fast with a clear error
No deprecation period: the fix is a one-line addition to phparkitect.php, so the error message is the migration guide. Each removed option keeps a defined-but-failing stub that tells you exactly what to do:
Error: the --target-php-version option has been removed, set it in your config file instead:
$config->targetPhpVersion(TargetPhpVersion::create('8.2'));
Keeping the options defined (but failing) is deliberate: simply removing them would make Symfony Console exit with a generic "option does not exist" error. The failing stubs can be dropped entirely in a later release. Same approach as #648.
Documentation
The README currently shows almost none of the Config setters. The setters for every config-only setting must be documented with examples, and the configuration reference should become prescriptive: for each setting, state where it belongs (config / CLI / both) rather than merely listing both. The precedence rule for options that remain in both places (CLI overrides config) should be stated explicitly.
Problem
Almost every option of
checkhas a twin setter inConfig, so the same setting can be expressed in two places. But some of these settings are properties of the project — they never legitimately change from one invocation to the next. For those, the CLI option is a liability: teams end up repeating them in every CI script instead of setting them once in the versioned config file, and two sources of truth invite drift.Guiding principle
phparkitect.phpis the project's source of truth. The CLI exists for bootstrap (where to find things) and for one-off overrides of a single run. The test for each option: is there a legitimate reason for this setting to vary between invocations? If not, it doesn't belong on the CLI.Classification
--config,--autoload--stop-on-failure,--format,--skip-baseline--target-php-version,--ignore-baseline-linenumbers,--use-baselineNote on
--target-php-version: it may look like a candidate for CI overrides (multi-PHP matrix), but it isn't — architectural rules are checked against one PHP version, the minimum the project supports. That's a property of the project, full stop.The
Configsetters for the "project property" rows already exist (targetPhpVersion(),ignoreBaselineLinenumbers(),baselineFilePath()), so removing an option is just dropping the flag and documenting the setter.Migration: fail fast with a clear error
No deprecation period: the fix is a one-line addition to
phparkitect.php, so the error message is the migration guide. Each removed option keeps a defined-but-failing stub that tells you exactly what to do:Keeping the options defined (but failing) is deliberate: simply removing them would make Symfony Console exit with a generic "option does not exist" error. The failing stubs can be dropped entirely in a later release. Same approach as #648.
Documentation
The README currently shows almost none of the
Configsetters. The setters for every config-only setting must be documented with examples, and the configuration reference should become prescriptive: for each setting, state where it belongs (config / CLI / both) rather than merely listing both. The precedence rule for options that remain in both places (CLI overrides config) should be stated explicitly.