Php_codesniffer: Enhancement: Allow for PHPUnit-like configuration

[localheinz]

It would be totally awesome if

• all of the arguments and options of phpcs were optional
• phpcs could be wholly configured by using a phpcs.xml (or phpcs.xml.dist) file

so that I can just run

$ vendor/bin/phpcs

and it will pick up the configuration as you are used to from phpunit.

/cc @mheap

[aik099]

Currently you can set some configuration options in standard itself and others via phpcs config-set.

[mheap]

The following phpcs.xml does what I'd expect:

<?xml version="1.0"?>
<ruleset name="Test Standardr">
    <rule ref="PSR2"/>
    <file>./src</file>
</ruleset>

However, if I remove the "file" line and try and specify a path to run against (./vendor/bin/phpcs src) it ignores the phpcs.xml file and defaults back to the PEAR standard

[gsherwood]

PHPCS already has a config file where you can override many defaults: https://github.com/squizlabs/PHP_CodeSniffer/wiki/Configuration-Options

Rulesets, and the phpcs.xml, can be used to override CLI settings when they are important to the standard (like tab-width and encoding).

I think I need a bit more information about what it is that you can't do so I can figure out the best way to add it.

[mheap]

@gsherwood --config-set works, but as it writes to vendor/squizlabs/php_codesniffer/CodeSniffer.conf, it means that every team member needs to run the --config-set commands every time they rebuild their vendor folder. If we could move the config from there into the phpcs.xml file (or preferably phpcs.xml.dist) then it allows us to specify standards at a project level, and people just have to clone and run

[Konafets]

I think you are looking for a feature which was introduced in 2.2.0. Its documented in the blog post https://www.squizlabs.com/php-codesniffer/2.2.0-released

[mheap]

Almost, @Konafets.

If I use the following phpcs.xml file and command line, it works as expected:

<?xml version="1.0"?>
<ruleset name="Test Standard">
    <rule ref="PSR2"/>
    <file>./src</file>
</ruleset>

./vendor/bin/phpcs

However, if I want to just specify the ruleset but not the file path, it ignores the phpcs.xml file and defaults back to the PEAR standard.

<?xml version="1.0"?>
<ruleset name="Test Standard">
    <rule ref="PSR2"/>
</ruleset>

./vendor/bin/phpcs src

I'm looking for a way to enable everything you can do in --config-set via a configuration file, so that I can have defaults in a config file but then override the values on the command line if required

[gsherwood]

I think what you are after is one of two options, but I'm not sure which is the best just yet:

Option 1: have PHPCS look for its config file in the current directory before looking in its default config location. The current dir config file settings would be set first, and the default location settings (the one the user set themselves) would be processed next and override the project defaults.

Option 2: have the phpcs.xml file either used entirely as defaults only OR have an option for each <arg> tag to say if the value is a default or if it is a mandatory value for the ruleset. So you could set, for example, the tab-width to 4 as a default, but then allow the user to override that value on the command line. Or you can set the tab-width to 4 and have it mandatory, so the user's options are always ignored (as they are now).

[mheap]

For me, option 1 is preferable. It would lead to the following option inheritance model:

• Read phpcs.xml.dist
• Read phpcs.xml
• Read vendor/squizlabs/php_codesniffer/CodeSniffer.conf (for backwards compatability)
• Read command line options

We'd also need the ability to set everything in phpcs.xml that you can set via --config-set

[gsherwood]

phpcs.xml is a ruleset file, which means it acts as a complete coding standard. This allows you to put your custom coding standard into your project's root dir and have PHPCS use that by default. That file cannot be reused as an alternative config file.

Option 1 would require you to put a CodeSniffer.conf file in your project's root directory and use the same PHP array format as the main config file. I'd probably need to have a CLI option for --config-set etc to use the local file or the default file, to make it easier to setup.

Thinking about the options a bit more, I could probably just do both as well. Having default values in rulesets rather than forced overrides might come in handy.

[mheap]

Having a Codesniffer.conf file works for me. I was thinking of reusing the existing file but if that's not a route you want to go down, another file is perfect.

Could we have support for codesniffer.conf and codesniffer.conf.dist? The dist file is useful to commit, whilst having a codesniffer.conf file would be useful to override it (but have in gitignore) for people that want to do things like disable colours on their machine.

[gsherwood]

Could we have support for codesniffer.conf and codesniffer.conf.dist?

I can do this, although I'm not really sure what how often it would get used given that the user can set their own personal defaults in the other config file. Can't hurt though.

[mheap]

The other config file would be wiped out when you regenerate your vendor folder. That's my only issue with using that file.

Having a .dist file is something people will be familiar with thanks to PHPUnit

[mryellow]

have PHPCS look for its config file in the current directory

As a new user, coming from other linters and code-style checkers mostly in JS ecosystem. This is the behaviour I expected out of the box.

I imagined PHPCS would read a file such as .jscsrc or .jshintrc and load whatever repo specific configuration for code-style.

Any setting specified here should over-write the default specified in global config.

No external commands should be required as this then requires scripts to bring dev environment up.

edit: Seems it can do this.... Not immediately apparent or documented. Also finding the rules in the source and what names apply to them is a bit convoluted. A documented list or example of all definitions ready for editing would be handy.

[gsherwood]

From version 2.5.0, the phpcs.xml file is used even if you specify files to check on the command line. It also looks up the tree to find a phpcs.xml anywhere in the project, and supports phpcs.xml.dist files. From version 3, it will do a better job of merging command line argument values with phpcs.xml values as well, although it works okay in 2.5.0.