There are a number of command-line options which will not run a scan, but will show different output.
When processing the CLI arguments, the Config class will hard exit as soon as it encounters one of these options and will disregard any options passed after.
In practice, this means that:
phpcs --colors --report-width=120 -h
... will show the help screen in color with a fixed report-width of 120, while:
phpcs -h --colors --report-width=120
... will show the help screen without colours and will use the default report width (width of current screen).
This applies to the following command-line options:
--version
--help/-h/-?
-i
--config-show
--config-set
--config-delete
Note: this doesn't apply to the following commands-line, which, while they do show different output, will finish reading the CLI arguments and will process the ruleset before exiting out:
-e
--generator=Text
While this is not necessarily problematic, it is a usability issue which I would like to see fixed.
And it ties in with another usability issue, which is that PHPCS will exit straight away when an invalid option setting is passed, like passing an invalid sniff code to the --sniffs= or --exclude= arguments, passing a non-existent directory/file path to the --cache, --basepath= or --bootstrap= option, passing an unknown option etc.
This results in the user getting one error at a time, fixing that error in the CLI arg, running again and potentially getting the next error.
Describe the solution you'd like
I think it would be good to investigate if PHPCS could read all CLI arguments before exiting.
For the commands which would not result in a scan, CLI arguments after the chosen option, should then be respected.
For commands which would result in a scan, PHPCS should still exit with an error once the CLI arguments have all been read, but should display all the errors in one go, making them all actionable in one go for the end-user, improving usability.
Additional context (optional)
Before work on this task can/should start, tests will need to be added for the Config class, which is currently largely untested.
mbomb007
commented
5 months ago
Is your feature request related to a problem?
There are a number of command-line options which will not run a scan, but will show different output.
When processing the CLI arguments, the
Configclass will hard exit as soon as it encounters one of these options and will disregard any options passed after.In practice, this means that:
... will show the help screen in color with a fixed report-width of
120, while:... will show the help screen without colours and will use the default report width (width of current screen).
This applies to the following command-line options:
--version--help/-h/-?-i--config-show--config-set--config-deleteNote: this doesn't apply to the following commands-line, which, while they do show different output, will finish reading the CLI arguments and will process the ruleset before exiting out:
-e--generator=TextWhile this is not necessarily problematic, it is a usability issue which I would like to see fixed.
And it ties in with another usability issue, which is that PHPCS will exit straight away when an invalid option setting is passed, like passing an invalid sniff code to the
--sniffs=or--exclude=arguments, passing a non-existent directory/file path to the--cache,--basepath=or--bootstrap=option, passing an unknown option etc.This results in the user getting one error at a time, fixing that error in the CLI arg, running again and potentially getting the next error.
Describe the solution you'd like
I think it would be good to investigate if PHPCS could read all CLI arguments before exiting.
For the commands which would not result in a scan, CLI arguments after the chosen option, should then be respected.
For commands which would result in a scan, PHPCS should still exit with an error once the CLI arguments have all been read, but should display all the errors in one go, making them all actionable in one go for the end-user, improving usability.
Additional context (optional)
Before work on this task can/should start, tests will need to be added for the
Configclass, which is currently largely untested.Related issues