Php-cs-fixer: Does PHP-CS-Fixer replace or complement PHPCS/PHPCBF?

[RinkAttendant6]

This is more of a question than a bug report or feature request.

Is it redundant for a project to use both PHPCS (and the corresponding fixer phpcbf) and PHP-CS-Fixer, or do the tools complement each other?

PHP-CS-Fixer certainly has a lot more to offer (short array syntax, null coalesce, etc.) Are there any features that PHPCS have that are missing from PHP-CS-Fixer?

Fixing (assuming configuration files are present)

vendor/bin/php-cs-fixer fix --verbose
vendor/bin/phpcbf 

Linting (again, assuming configuration files are present):

vendor/bin/php-cs-fixer fix --dry-run --verbose
vendor/bin/phpcs

Both tools return non-zero exit code in the case of error

[keradus]

Hi @RinkAttendant6 !

There are 2 different ideas behind the tools.
PHP Coding Standards Fixer since beginning was created with "fixer" approach in mind, only fixer. The "linting" feature is just a side-effect of using dry-run.
PHP Code Sniffer was created with "linting" approach, and after few years of having PHP CS Fixer in ecosystem, PHPCS started to fix as well.
So, what is the diff, you could say? PHP CS Fixer is for full automation, if it cannot fix sth (maybe rule is discussable? maybe it could be changed in several ways?), we don't check it at all. PHP CS on the other side will still report it.

Different features? For sure. PHP CS Fixer has almost 200 rules, there are a lot of rules that are not there in PHPCS and vice versa.
PHPCS has 2 "big" features that are not present in PHP CS Fixer by purpose - linting CSS and JS files. at PHP CS Fixer, we do believe that the single tool per language is better approach, resulting with great tools like tslint, eslint or css lint, style lint.

[RinkAttendant6]

@keradus Thanks for the prompt reply! In this case I'll keep both tools then. With caching they are fast enough to be run in my project's lint task.

I did notice that after running PHP CS Fixer on my project (that passed PHPCS), there was one method that ended up with too many blank lines before the closing brace that failed PHPCS, but other than that everything went well 😺.

[keradus]

With different rules and features, they could be conflicting sometimes ;)

In case of using multiple tools, consider using https://github.com/phpro/grumphp .

If you consider this thread as resolved, please close it.

[TomasVotruba]

@RinkAttendant6 They're actually overlapping less and less, the best is to use both of them.

Though they overlap, each is best at one job:

• Sniffs check - "hey, this is not nice, do something about it"
• Fixers change - "no wories, we just fixed it all for you"

Also, communities grow appart:

• In PHP_CodeSniffer community there is a great slevomat/coding-standard package, that automated PHP 7.0 typehint migration very well + other 20-30 useful rules: https://github.com/slevomat/coding-standard

• PHP CS Fixer still doesn't support this yet, and PHP 7.3 is round the corner

• In Symplify there are both fixers and sniffs, mostly focusing on architecture and advanced checks https://github.com/symplify/codingstandard#rules-overview

• PHP_CodeSniffer has already released few PSR12 sniffs - https://github.com/squizlabs/PHP_CodeSniffer/pull/2022

• PHP CS Fixer on the other hand focuses on details and precise work with tokens, like comment malforms, spaces and many cases I would never think are covered

• They're both active, many released per year, jumped both by 1 k+ starts this year.

Saying that, it's the best to have both on-board :100: