Feature request: make default extension configurable inside CodeSniffer.conf

[josias-r]

Currently, you can only check files like phtml using the cli argument --extensions=phtml. I would prefer the possibility to set custom extensions inside the config file because it's easier to configure CadeSniffer project-wise.

[jrfnl]

@josias-r Could it be that you are confusing the config file with the ruleset file ?

The config file CodeSniffer.conf contains basic defaults like the installed (external) standards and the default standard for all projects and is located in the root of the PHP_CodeSniffer directory.

The [.]phpcs.xml[.dist] ruleset file is typical placed in the root of a project and contains the rules which apply to that project, including which extensions need to be scanned.

<?xml version="1.0"?>
<ruleset name="Project Coding Standard">
    <description>The Coding standard for Project.</description>

    <!-- Scan all files. -->
    <file>.</file>

    <!-- Check PHP and PHTML files. -->
    <arg name="extensions" value="php,phtml/php"/>

    <rule ref="PSR12"/>

</ruleset>

More information can be found in the Wiki:

• https://github.com/squizlabs/PHP_CodeSniffer/wiki/Configuration-Options
• https://github.com/squizlabs/PHP_CodeSniffer/wiki/Annotated-Ruleset

[josias-r]

I did just switch to the custom ruleset. My initial thought was this: "I want to use Symfony as my coding standard and am working with phtml files". I guess it's more of a mindset. If you count extensions part of a coding standard definition, it makes sense to create a "custom" ruleset extending a coding standard. To me, extensions are rather a configuration of the tool used to lint your code, than "part of the definition" of a coding standard.

Also, of course, technically it's already working to do that as you mentioned, I just think it's the wrong place where something like that should be configured. It was confusing for me to find out where I can do this until I found out about the ruleset.

[gsherwood]

A ruleset.xml file that you include within the root of your project defines the way that project needs to be checked. It is a better version of the original CodeSniffer.conf file as this applies globally and so has limited use in a multi-project environment.

You can't commit a CodeSniffer.conf file because it would change how every developer on a project runs PHPCS on all other projects. But the ruleset.xml can be committed as it only applies when checking the specific project it exists within.

It's also important to understand that as soon you do something like --exclude=standard.category.sniff or --extensions=phtml on the command line, you are altering the standard of the project by deciding what errors should be returned. If you aren't working with anyone on the project I can see how this would feel like a waste of time, but if you ever share this code it's really good to have a record of what code should be checked, and how.

Hopefully that makes sense, and explains why the ruleset.xml method is the preferred method for hard-coding config values.

[josias-r]

Alright, makes perfectly sense to me now, thanks for the explanation! Maybe mention this in the documentation. It took me quite some time just to figure it out 😛