Integrate PHP_CodeSniffer into build/test tools to enforce coding standards on new patches

[westonruter]

There is a community project to develop PHP_CodeSniffer standard(s) for the WordPress Coding Standards: ​https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards

Currently it only (mainly) applies to PHP files, though PHP_CodeSniffer can also tokenize and apply sniffs to JS and CSS.

It would be helpful if PHP_CodeSniffer could automatically check new patches being committed, to incorporate it into a pre-commit hook. A key here is to restrict PHP_CodeSniffer to only report errors and warnings on the lines that are part of the patch being committed. There is an initial version of such a “phpcs-patch” script which needs to be tested and integrated into the build/test tools: ​https://github.com/xwpco/PHP_CodeSniffer/pull/1

[valendesigns]

+1

[westonruter]

See #34694.

[netweb]

Related: #41057

[pento]

@westonruter: Did you ever get phpcs-patch merged upstream?

A reasonable first version of this could just run phpcbf on any changed files (after another full phpcbf run is done on trunk, of course).

[westonruter]

@pento No, it was not merged. But there is an implementation of it in ​wp-dev-lib in its ​check-diff.sh and accompanying diff tools.

However, @jrf has wisely pointed out that it is unreliable to filter out errors that aren't related to the lines in a diff. That is, errors can slip through. For example, when applying to approach to JSHint, if a variable is removed but then its var remains then an error will slip through regarding an unused variable.

[pento]

That's a good point.

Okay, let's go with running phpcbf as a first version, it can be changed to phpcs if we ever manage to fix all of coding standards issues that require manual intervention. 🙂

[pento]

Given that phpcs-patch doesn't appear to be a viable option, I'm closing this in favour of adding the phpcbf check in #44600.