Skip to content

Feature suggestion: Improve information available about installed standards #17

Open
@jrfnl

Description

@jrfnl

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:    90                                                                                                                                         

I 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/WPThemeReview

For standards which do not (yet) supply the version number via the ruleset.xml file, it could be tried to retrieve the version number via a composer --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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions