Weave Code
Php Codesniffer Laravel Package
phpcsstandards/php_codesniffer
PHP_CodeSniffer is a PHP library that tokenizes PHP, JavaScript, and CSS files to detect violations of a defined coding standard. It includes phpcs for detecting violations and phpcbf for automatically fixing them, ensuring consistent, clean code across your projects.
PHP_CodeSniffer tokenizes PHP files and detects violations of a defined set of coding standards.
Frequently asked questions about Php Codesniffer
- How do I install PHP_CodeSniffer in a Laravel project?
- Install it as a development dependency with Composer using the phpcsstandards/php_codesniffer package name. Most teams also add dealerdirect/phpcodesniffer-composer-installer so installed coding standards are registered automatically. Then create a phpcs.xml ruleset at the project root and run vendor/bin/phpcs from the CLI or a Composer script. No service provider or Laravel registration is required.
- Should PHP_CodeSniffer go in require or require-dev?
- It belongs in require-dev. PHP_CodeSniffer is developer tooling that runs from the command line and in CI, and it has no runtime, database, queue, or HTTP surface inside your application. Keeping it out of require means production deployments never download the tokenizer or its standards. It also keeps your production autoload classmap free of linter code.
- What is the difference between PHP_CodeSniffer and Laravel Pint?
- Pint is built on PHP-CS-Fixer and focuses on formatting and style consistency. PHP_CodeSniffer is a tokenizer-based rule engine that supports custom sniffs, security rules, and framework-specific checks you can write yourself. If you only need formatting, Pint is simpler. If you need extensible static rule enforcement, PHPCS is the stronger fit, and some teams run both with a documented split of responsibilities.
- Why does Composer fail with a plugin not allowed error when installing PHP_CodeSniffer?
- Composer 2.2 and later blocks plugins unless they are explicitly allowed. Standards discovery relies on dealerdirect/phpcodesniffer-composer-installer, so you must add it to the allow-plugins section of composer.json or installs will fail, especially in non-interactive CI environments. Commit that configuration so every environment resolves identically.
- How do I migrate from squizlabs/php_codesniffer to phpcsstandards/php_codesniffer?
- PHP_CodeSniffer is now maintained by PHPCSStandards, so the Composer name and namespace differ from the legacy Squizlabs package. Replace the old requirement rather than adding the new one alongside it, because both packages provide the same binaries and will conflict. After switching, run composer update for the package and re-verify that your installed standards still declare compatible PHPCS version constraints. Then re-run phpcs to confirm the ruleset behaves the same.
- Can PHP_CodeSniffer fix coding standard violations automatically?
- Yes. The bundled phpcbf binary applies automatic fixes for the majority of style sniffs. The recommended approach is to run it once in a single isolated style-only commit so review noise stays out of feature pull requests. Not every sniff is fixable, so expect a residual set of manual findings. Auto-fix output can change between minor releases, so pin the version before running it across a large codebase.
- How do I run PHP_CodeSniffer in GitHub Actions or GitLab CI?
- Add a CI step that runs vendor/bin/phpcs against your committed ruleset. Use the checkstyle report format so GitHub Actions or GitLab can annotate the offending lines directly in the diff, and use json or summary output for dashboards and human logs. PHP_CodeSniffer exits non-zero when violations are found, so the step fails the build without extra scripting. Pin the package version in CI so results match local runs.
- How do I adopt PHP_CodeSniffer on an existing Laravel codebase without a massive diff?
- Do not attempt a big-bang cleanup on a mature repository. Instead, baseline the current violations using a suppression file or scope the ruleset to new and changed code only, then make CI blocking against that scoped ruleset. Shrink the baseline incrementally, directory by directory or module by module. This ratchet approach keeps enforcement real while keeping pull requests reviewable.
- Can I use PHP_CodeSniffer together with PHPStan or Psalm?
- Yes, and they solve different problems. PHP_CodeSniffer handles tokenization and coding-standard enforcement, while PHPStan and Psalm perform type and flow analysis. They coexist cleanly with no shared runtime or conflicting configuration. Treat them as complements in the same pipeline rather than replacements for one another.
- How do I stop local and CI PHP_CodeSniffer results from diverging?
- Pin the package and the standards-discovery plugin to explicit versions and commit composer.lock so every environment resolves the same tree. Check that the PHP version used locally matches the CI runtime, since tokenizer support depends on the language version in use. Be aware that sniff behavior and auto-fix output can change across minor releases, so review changelogs before upgrading. Unpinned upgrades can rewrite large diffs unexpectedly.
Weaver
How can I help you explore Laravel packages today?