Description
Repost from squizlabs/PHP_CodeSniffer#2600:
(I seem to remember seeing a discussion about something like this before, but can't find it anymore, so hoping I'm not opening a duplicate issue)
At this moment, there is the
--version
option to show the version of PHPCS itself, the-i
option to show which (external) standards are installed and the--config-show
option which provides information on the configuration used.# phpcs --version PHP_CodeSniffer version 3.5.0 (stable) by Squiz (http://www.squiz.net) # phpcs -i The installed coding standards are MySource, PEAR, PSR1, PSR12, PSR2, Squiz, Zend, PHPCompatibility, Debug, PHPCSDev, WordPress, WordPress-Core, WordPress-Docs, WordPress-Extra, WPThemeReview, Joomla and Symfony # phpcs --config-show Using config file: /path/to/PHP_CodeSniffer/CodeSniffer.conf installed_paths: /path/to/PHPCompatibility,/path/to/PHPCSDevTools,/path/to/WordPress,/path/to/WPThemeReview,/path/to/Joomla-coding-standards,/path/to/Symfony-coding-standard report_width: 90I believe it would be helpful if there was a command-line option available which would combine some of this information.
For this to work as I envision, external standards would need to be allowed to pass their version number on to PHPCS through the XML ruleset.
Something along the lines of:
<ruleset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="PHPCSDev" namespace="PHPCSStandards\PHPCSDev" version="1.0.0" xsi:noNamespaceSchemaLocation="https://raw.githubusercontent.com/squizlabs/PHP_CodeSniffer/master/phpcs.xsd"> ... </ruleset>This would require a change to the
phpcs.xsd
file along the lines of adding the below to the<xs:element name="ruleset">
block:<xs:attribute name="version" type="xs:string"></xs:attribute>Secondly, either one of the above mentioned command-line options would need to be adjusted or a new one should be introduced, let's call it
--list-standards
for now.I imagine the output could then look something like this:
# phpcs --list-standards PHP_CodeSniffer version 3.5.0 (stable) by Squiz (http://www.squiz.net) Standards | Version | Installed path --------------------------------------------------------------- MySource | 3.5.0 | N/A (build-in) PEAR | 3.5.0 | N/A (build-in) PSR1 | 3.5.0 | N/A (build-in) PSR2 | 3.5.0 | N/A (build-in) PSR12 | 3.5.0 | N/A (build-in) Squiz | 3.5.0 | N/A (build-in) Zend | 3.5.0 | N/A (build-in) Debug | 1.0.0 | /path/to/PHPCSDevTools Joomla | 2.0.0-rc3 | /path/to/Joomla-coding-standards PHPCompatibility | 9.3.0 | /path/to/PHPCompatibility PHPCSDev | 1.0.0 | /path/to/PHPCSDevTools Symfony | 3.9.0 | /path/to/Symfony-coding-standard WordPress | 2.1.1 | /path/to/WordPress WordPress-Core | 2.1.1 | /path/to/WordPress WordPress-Docs | 2.1.1 | /path/to/WordPress WordPress-Extra | 2.1.1 | /path/to/WordPress WPThemeReview | 0.2.0 | /path/to/WPThemeReviewFor standards which do not (yet) supply the version number via the
ruleset.xml
file, it could be tried to retrieve the version number via acomposer --show
in case of a Composer based install.For non-Composer based installs, the version could either be left empty of be listed as
Unknown
.Also take note of the ordering of the list: build-in standards first and then external standards in alphabetic order using natsort.
Opinions ?
See the original issue for additional considerations.