Weave Code
Php Cs Fixer Laravel Package
friendsofphp/php-cs-fixer
PHP CS Fixer automatically detects and fixes coding standards issues in your PHP code. Choose from built-in rule sets like @PER-CS, @Symfony, or @PhpCsFixer, or define your own style, and modernise your codebase with ease.
PHP CS Fixer automatically detects and fixes PHP coding-standard violations, eliminating tedious manual cleanup across large codebases. It provides built-in and community rule sets such as @PER-CS, @Symfony, and @PhpCsFixer, along with configurable rules for team-specific style.
- Automatically fixes style issues project-wide
- Built-in rule sets and custom configuration
- Modernizes code for newer PHP and PHPUnit versions
- Supports PHP 7.4–8.5 plus Composer, Docker, and CI workflows
Frequently asked questions about Php Cs Fixer
- How do I install PHP CS Fixer in a Laravel project?
- Install it as a dev dependency with composer require --dev friendsofphp/php-cs-fixer, which places the binary at vendor/bin/php-cs-fixer. If Composer reports a dependency conflict, install the PHAR-based php-cs-fixer/shim package instead. After installing, create a .php-cs-fixer.dist.php config file defining the paths and rule sets you want, then commit that file so the whole team formats code identically.
- Which rule set should a Laravel project use: @Symfony, @PER-CS, or @PhpCsFixer?
- Most Laravel codebases start with @Symfony because it closely matches the conventions Laravel itself follows, and you can layer @PER-CS on top for PHP-FIG alignment. @PhpCsFixer is more opinionated and will produce a bigger diff on legacy code, so adopt it only if the team agrees to its stricter style. All three are starting points: you can override individual rules in the config to match your team's preferences.
- Which PHP and Laravel versions does PHP CS Fixer support?
- The tool supports PHP 7.4 through PHP 8.5, so it works with any current Laravel release and its minimum PHP requirements. Support for a brand-new PHP version sometimes lags slightly because new syntax needs dedicated fixers and parsers. On an unsupported runtime you can pass --allow-unsupported-php-version=yes, but that is at your own risk.
- How do I make CI fail when code violates coding standards?
- Run PHP CS Fixer with --dry-run --diff in your pipeline instead of --fix, so it reports violations and exits non-zero without rewriting files. Typical setups run this in GitHub Actions or GitLab CI as a dedicated style job before tests, and developers run the fixer locally or via a pre-commit hook. Auto-fixing in CI is possible but tends to obscure what changed, so most teams only check there.
- How can I speed up PHP CS Fixer on a large Laravel codebase?
- Use the --parallel flag to split work across processes, and keep the .php-cs-fixer.cache file so unchanged files are skipped on subsequent runs. You can also limit the Finder paths to app, config, database, routes, and tests rather than scanning the entire repository. In CI, caching or restoring the cache file between runs gives a large speedup on matrix jobs.
- Should I persist the .php-cs-fixer.cache file between CI runs?
- Persisting the cache can meaningfully cut runtime on large codebases, but it is optional and running cold is the most deterministic choice. If you do persist it, require version 3.95.27 or newer, because that release validates a corrupt cache on load and rebuilds it instead of aborting the run. That version also refuses a symlinked cache path and creates cache files with more moderate permissions, which matters on shared or self-hosted runners.
- Is upgrading to PHP CS Fixer 3.95.27 safe, or will it reformat my whole codebase?
- The 3.95.27 release is a patch-level update with no new fixers, no deprecations, and no rule-behavior changes that would alter formatted output. Its changes are reliability and security hardening of the cache layer, so a single composer update is normally all that is needed. The only integration surface that sees a behavioral difference is CI pipelines that persist cache artifacts, where the new validation behavior is an improvement.
- Does PHP CS Fixer handle Laravel Facades, service providers, and Blade templates?
- It operates on PHP files, so .blade.php templates are not formatted by the standard rule sets and need separate tooling. Rules such as NoUnusedImports can occasionally misfire in Laravel code that relies on dynamic class loading, string-based class references, or facade aliases. The fix is to whitelist or disable that specific rule in your config rather than abandoning the rule set.
- Can PHP CS Fixer modernize my code for newer PHP and PHPUnit versions?
- Yes. The @autoPHPMigration and @autoPHPMigration:risky rule sets rewrite syntax toward newer PHP versions, and @autoPHPUnitMigration:risky updates deprecated PHPUnit patterns. These are especially useful when a Laravel app moves to PHP 8.2 or later. Run them on a dedicated branch and review the diff, since migration rules change code semantics more than pure style rules do.
- How does PHP CS Fixer compare to Laravel Pint and other alternatives?
- Laravel Pint is a thin wrapper around PHP CS Fixer with a preset Laravel-friendly configuration and zero setup, whereas PHP CS Fixer gives you full control over rule sets, Finder paths, and risky rules. If you want the Laravel default style with no configuration, Pint is simpler; if you need custom rule sets, auto-migration rules, or non-Laravel code in the same repo, PHP CS Fixer is the more flexible choice. PHP_CodeSniffer with PHPCBF is the other common option, but it is slower and its fixing support is narrower.
Weaver
How can I help you explore Laravel packages today?