wyrihaximus/coding-standard
wyrihaximus/coding-standard is a PHP coding standard package for defining and enforcing consistent code style across PHP projects. It provides a shared standard to help keep formatting and conventions uniform in a codebase.
wyrihaximus/coding-standard is a PHP_CodeSniffer ruleset, not a formatter or a Laravel package. It bundles doctrine/coding-standard, slevomat/coding-standard and squizlabs/php_codesniffer into a single standard registered under the name WyriHaximus. You install it for linting (phpcs) and auto-fixing (phpcbf); it does nothing at runtime.
composer require --dev wyrihaximus/coding-standard
Composer 2.2+ will prompt to allow the plugin; if you run non-interactively add it to composer.json first:
"config": {
"allow-plugins": {
"dealerdirect/phpcodesniffer-composer-installer": true
}
}
The installer registers the standard automatically, so confirm it is visible before writing any config:
vendor/bin/phpcs -i # should list "WyriHaximus"
vendor/bin/phpcs -e --standard=WyriHaximus # lists every sniff in the ruleset
Then create phpcs.xml.dist at the project root:
<?xml version="1.0"?>
<ruleset name="App">
<description>App coding standard</description>
<file>app</file>
<file>config</file>
<file>database</file>
<file>routes</file>
<file>tests</file>
<arg name="extensions" value="php"/>
<arg name="colors"/>
<arg value="ps"/>
<exclude-pattern>*/vendor/*</exclude-pattern>
<exclude-pattern>*/storage/*</exclude-pattern>
<exclude-pattern>*/bootstrap/cache/*</exclude-pattern>
<exclude-pattern>*/_ide_helper*.php</exclude-pattern>
<rule ref="WyriHaximus"/>
</ruleset>
First use case: run it read-only on a single small directory first, because the first run on an existing Laravel app will produce hundreds of violations.
vendor/bin/phpcs app/Http/Controllers # report only
vendor/bin/phpcs -s app/Http/Controllers # -s prints the sniff code, needed for exclusions
Where to look first: the package's ruleset.xml (in vendor/wyrihaximus/coding-standard/). The README is a one-liner, so the XML is the only real documentation of what is enforced. The release notes tell you what changes between versions; there is no usage guide.
Note the platform requirements: PHP 8.2+ since 2.15.0, PHP_CodeSniffer v4 since 3.0.0. A Laravel app pinned to PHP 8.1 cannot install current versions.
Composer scripts — the day-to-day entry points:
"scripts": {
"lint": "phpcs",
"lint:fix": "phpcbf"
}
CI — one step, cached where possible:
- run: composer install --no-interaction --prefer-dist
- run: vendor/bin/phpcs --report=full --report-summary
Incremental adoption. Do not enable the full standard on a legacy app and block the build. Either scope the ruleset to new code, or lint only changed files:
git diff --name-only --diff-filter=ACM origin/main... | grep '\.php$' | xargs vendor/bin/phpcs
Composing with your own rules. The useful pattern is a project ruleset that references the package and subtracts the parts you disagree with. Get the codes from phpcs -s:
<rule ref="WyriHaximus">
<exclude name="SlevomatCodingStandard.Commenting.UselessFunctionDocComment"/>
<exclude name="SlevomatCodingStandard.TypeHints.DeclareStrictTypes"/>
</rule>
Per-directory overrides. tests/ and migrations almost always need a looser profile:
<rule ref="WyriHaximus">
<exclude-pattern>database/migrations/*</exclude-pattern>
</rule>
Coexistence with Pint. Laravel ships Pint; this standard is stricter and overlapping. Pick an order and stick to it — Pint formats, phpcs verifies. Never chain phpcbf and Pint in the same pre-commit hook on the same file, or you get fight loops on whitespace/import ordering.
Editor integration. Point the VS Code phpcs extension or Intelephense's intelephense.environment.phpcsStandard at the standard name WyriHaximus so violations appear while typing; otherwise the feedback loop is a slow terminal round trip.
Pre-commit. A git hook running phpcs on staged files only (via captainhook or a small shell script) catches the most common offenders — unused imports, missing trailing commas, non-alphabetised use statements — before review.
Realistic position: this is a package-authoring standard (it is what WyriHaximus applies to his own libraries), not an app standard. If you are publishing a Composer library from inside a Laravel monorepo, apply it to packages/*/src only and leave app/ on Pint.
doctrine/coding-standard + slevomat/coding-standard referenced directly in your own XML is the lower-risk equivalent."wyrihaximus/coding-standard": "4.0.0") and upgrade deliberately, otherwise CI goes red on a dependency update you didn't write.@api from forbidden annotations. Read composer.json constraints before running composer update.WyriHaximus, not wyrihaximus/coding-standard and not WyriHaximus\CodingStandard. If phpcs -i doesn't list it, the installer plugin was skipped (usually the allow-plugins issue above).declare(strict_types=1) is enforced and is a big diff. Slevomat's strict-types sniff wants it in every file. Roll it out directory by directory rather than in one PR, and exclude files that legitimately can't have it.storage/, bootstrap/cache/, public/build/, vendor/, _ide_helper.php, *.php in resources/views if you have any. Otherwise runs get slow and noisy.phpcbf rewrites files in bulk. Commit or branch first, run phpcbf on a subset, then git diff to review. A single phpcbf on a large legacy app/ produces an unreviewable commit.phpcs -s gives you e.g. SlevomatCodingStandard.Namespaces.ReferenceUsedNamesOnly.MissingImport. Partial names work only up to a category, so copy the exact string.exclude list (documented and shrinking) or gate CI to changed files. Check whether your installed major supports --generate-baseline before reinventing it.phpcs.xml. Anything you want changed, you patch in your own ruleset.How can I help you explore Laravel packages today?