Automated Tooling
Expecting every one of these rules to be checked by hand, every time, isn't realistic — eyes get tired and standards slip through. The tools in this chapter exist to catch what a human reviewer shouldn't have to.
1. PHP_CodeSniffer and Coder
PHP_CodeSniffer, combined with the Coder module's Drupal and DrupalPractice rulesets, is what actually encodes the PHP, YAML, and documentation standards covered in the earlier chapters into something a computer can check.
composer require --dev drupal/coder2. Running phpcs and phpcbf
Once installed, phpcs scans a directory and lists every violation it finds, file and line number included; phpcbf, its companion, automatically fixes the subset of violations that have an unambiguous fix — most whitespace and formatting issues, though rarely anything structural.
vendor/bin/phpcs \
--standard=Drupal,DrupalPractice \
web/modules/custom
vendor/bin/phpcbf \
--standard=Drupal \
web/modules/custom3. PHPStan and phpstan-drupal
phpcs only ever looks at formatting — it has no idea whether a method call is valid or a variable holds the type it's supposed to. That's what PHPStan, extended with the phpstan-drupal rules, is for: real static analysis that catches a wrong method call, a mismatched type, or a reference to something that doesn't exist, all without running the code at all.
composer require --dev phpstan/phpstan mglaman/phpstan-drupal4. ESLint and Stylelint
The JavaScript and CSS standards covered earlier have their own tools: ESLint for JavaScript, using the configuration Drupal core ships with, and Stylelint for CSS. Both run the same way phpcs does — point them at a directory, read the list of violations.
5. Editor Integration
None of these tools are much good if they only ever run right before a commit. Wiring phpcs, ESLint, and Stylelint into an editor — most IDEs support this through a plugin — surfaces a violation the moment it's typed, which is a far shorter feedback loop than waiting for a pipeline to fail.