- Does wyrihaximus/coding-standard work with Laravel applications?
- It can be installed in a Laravel project, but it is not a Laravel package. It is a PHP_CodeSniffer ruleset that lives in require-dev and is referenced from a phpcs.xml file, with no service provider, config publishing, migrations, or runtime coupling. That gives it effectively zero production blast radius, but it also means Laravel-specific conventions are not built in, so expect to extend the standard or disable some sniffs.
- How do I install wyrihaximus/coding-standard?
- Install it as a dev dependency with composer require --dev wyrihaximus/coding-standard. The dealerdirect/phpcodesniffer-composer-installer plugin registers the standard so PHP_CodeSniffer can resolve it by name. After that you reference the standard from a project-owned phpcs.xml and run phpcs or phpcbf through a Composer script or CI job.
- How do I configure phpcs.xml to use this coding standard?
- Create a phpcs.xml at the project root and add a rule reference to the standard name registered by the Composer plugin, scoped to your source directories. Extend the upstream standard rather than consuming it wholesale so you have a seam to exclude noisy sniffs without forking. Wire the same file into CI, a local composer lint script, and your IDE inspection so failures show up before pushing.
- Will this conflict with Laravel Pint?
- Likely yes, because Pint is PHP-CS-Fixer based and overlaps heavily with a PHPCS ruleset. Running both produces conflicting auto-fixes and duplicate, differently worded failures on the same lines. Decide up front whether PHPCS is the sole gate, Pint is the sole gate, or you split responsibilities with Pint owning formatting and PHPCS owning structural or semantic sniffs only. Also avoid running phpcbf and Pint in the same pass.
- What standards does this ruleset actually aggregate?
- It is a meta-ruleset that pulls together doctrine/coding-standard, slevomat/coding-standard, and squizlabs/php_codesniffer, registered via the PHP_CodeSniffer Composer installer. The original code surface is small, but the dependency surface, and therefore the behavioral surface, is large. Most rule changes will arrive through upstream bumps rather than changes in this repository.
- Does it affect production runtime or autoloading?
- No. It is a require-dev tool with no service provider, no migrations, and no runtime integration, so it should never be installed in production. Keep it out of production installs by using composer install --no-dev. The only real impact is on local tooling, CI time, and code review output.
- Which PHP and PHPCS versions does it require?
- The release history raised the PHP minimum to 8.2 and later to 8.4, and moved to PHP_CodeSniffer 4 in version 3.0.0. Check the exact constraint on the version you plan to pin instead of assuming. If you are on PHPCS 4, confirm your IDE integration and CI tooling support the major, since third-party tooling often lags PHPCS majors.
- Does it produce false positives on Eloquent models, facades, and magic methods?
- Expect meaningful triage there. Doctrine and Slevomat rules are opinionated about declare(strict_types=1) in every file, alphabetical use ordering, early exits, and forbidden annotations, which can collide with idiomatic Laravel code. Run the ruleset in report-only mode first, classify violations as mechanically fixable versus false positives, and disable the noisy sniffs in your own phpcs.xml rather than forking.
- Is it safe to rely on given the maintenance and bus factor?
- The repository has a single visible maintainer, zero stars, zero dependents, and releases dominated by Renovate dependency bumps. That is a bus factor of one, and you would be among the first substantive consumers. Pin a version, and be prepared to wrap or fork the ruleset if upstream goes quiet; because it tracks upstream closely, your CI output can change without your code changing.
- What alternatives should I consider before adopting it?
- Consider a PSR-12 baseline, doctrine/coding-standard or slevomat/coding-standard applied directly with selected sniffs, PHP-CS-Fixer, or Laravel Pint as the sole formatter. Extending PSR-12 with a handful of Slevomat sniffs often achieves the same review-load and onboarding goals with less dependency risk. If you adopt this ruleset anyway, start report-only in one repository and measure the violation inventory before making it blocking in CI.