Weave Code
Code Sniffer Laravel Package
php-collective/code-sniffer
A PHP_CodeSniffer ruleset that follows PSR-2 and PSR-12 with many extra fixers on top, plus a stricter PhpCollectiveStrict standard. Install via Composer, add it to phpcs.xml, and run phpcs/phpcbf or composer scripts to check and auto-fix code style.
PhpCollective Code Sniffer Standards
Frequently asked questions about Code Sniffer
- How do I install php-collective/code-sniffer in a Laravel project?
- Install it as a development dependency with composer require --dev php-collective/code-sniffer. It is a ruleset distribution for PHP_CodeSniffer, not a runtime library, so it never ships to production. After installing, create a phpcs.xml in your project root that references vendor/php-collective/code-sniffer/PhpCollective/ruleset.xml.
- How do I configure phpcs.xml to use the PhpCollective ruleset?
- Add a ruleset element with the directories you want scanned, for example src/ and tests/, and reference the bundled ruleset with a rule ref pointing at vendor/php-collective/code-sniffer/PhpCollective/ruleset.xml. You can exclude files, silence individual sniffs, or add extra rules inside the same file. Once configured, vendor/bin/phpcs checks your code and vendor/bin/phpcbf applies fixes.
- Does this package support PSR-12 as well as PSR-2?
- Yes. The PhpCollective standard fully implements PSR-2 and bundles PSR-12 support plus many additional fixers. On top of the PSR sniffs it adds around 250 sniffs from Generic, PSR1/2/12, Slevomat, and its own PhpCollective-specific rules. That means you get base PSR compliance and opinionated house conventions in a single ruleset.
- What is the difference between the PhpCollective and PhpCollectiveStrict standards?
- PhpCollective is the default standard and covers PSR-2/PSR-12 plus the package's additional fixers. PhpCollectiveStrict extends it with its own stricter sniffs layered on top. Because both are shipped together, you can start with PhpCollective and switch to the strict standard later for a phased rollout instead of a single big-bang style gate.
- Which PHP and Laravel versions does php-collective/code-sniffer support?
- It requires PHP 8.1 or newer and is itself developed against PHPStan level 8. Because it is a dev-only Composer tool with no runtime coupling to application code, it fits any Composer-based Laravel project running PHP 8.1+. You should still confirm the bundled PHP_CodeSniffer and Slevomat versions are compatible with what your project already has installed.
- Is it safe to run phpcbf auto-fix unattended in a pre-commit hook?
- No, treat phpcbf output as code changes that need review. Version 0.6.9 fixed three fixer bugs that produced broken or semantically wrong output, including a parse error on first-class callables and incorrect |array and @throws annotations. Those kinds of silent corruption can pass a green build and only surface in review or at runtime, so diff the fixer output rather than trusting a passing exit code.
- How do I add cs-check and cs-fix Composer scripts for CI?
- Add a scripts block to composer.json with entries such as cs-check mapping to phpcs -nps and cs-fix mapping to phpcbf -nps. Then run composer cs-check in CI to fail builds on style violations and composer cs-fix locally to auto-fix. Using the -nps flags keeps output clean by removing warnings, progress, and sniff source noise.
- Do I still need Laravel Pint if I use this ruleset?
- Pint and this package solve overlapping but different problems, and they are complementary rather than interchangeable. PHP_CodeSniffer with the PhpCollective ruleset gives you opinionated sniffs and fixers for docblocks, type hints, array syntax, namespace and use ordering, and test conventions. Many teams run one as the formatter and the other as the strict style gate, but you should pick one source of truth for auto-fixing to avoid fighting formatters.
- Will it conflict with slevomat/coding-standard or squizlabs/php_codesniffer already in my project?
- Conflicts are plausible and worth checking before adoption. The package bundles its own compatible PHP_CodeSniffer major and Slevomat version, so if your project already requires slevomat/coding-standard or squizlabs/php_codesniffer directly, Composer may refuse to resolve or pick versions you did not expect. Run a dry-run composer require first and check the resolved versions.
- Is it safe to use a caret constraint like ^0.6 and upgrade patch versions freely?
- Be cautious, because the project is pre-1.0 and its sniffs and fixers are still moving. Patch releases have changed findings and fixer output, for example 0.6.9 made DocBlockThrows detect qualified relative exception names, which surfaces new violations on unchanged code. Pin an exact version and treat every upgrade as a ruleset change that requires a diff review, not a routine dependency bump.
Weaver
How can I help you explore Laravel packages today?