- How do I install kubawerlos/php-cs-fixer-custom-fixers in a Laravel project?
- Run composer require --dev kubawerlos/php-cs-fixer-custom-fixers. It belongs in require-dev because it is only used by PHP CS Fixer during development and CI. Then register the fixers in your PHP CS Fixer configuration. If you use php-cs-fixer/shim, include the package bootstrap file as the README notes.
- How do I register the custom fixers in PHP CS Fixer?
- In your .php-cs-fixer.php or php-cs-fixer.config.php, call registerCustomFixers(new PhpCsFixerCustomFixers\Fixers()) on the config object. Enable individual rules with PhpCsFixerCustomFixers\Fixer\SomeFixer::name() => true in setRules. Ensure Composer autoloading is available to the PHP CS Fixer process.
- Does this package work with Laravel Pint?
- Laravel Pint is built on PHP CS Fixer, but Pint's preset-based config may not expose every PHP CS Fixer extension point. If your Pint version supports custom fixer registration, use that; otherwise run these fixers through a separate PHP CS Fixer config. Test in a branch because Pint and standalone PHP CS Fixer can apply overlapping rules.
- Which PHP CS Fixer and PHP versions are supported?
- Exact constraints are declared in the package composer.json and on Packagist. Because custom fixers depend on PHP CS Fixer internals, choose a package release that matches your installed PHP CS Fixer major version. Run composer why-not if Composer reports a conflict.
- What fixers does this package provide?
- It provides many niche PHP CS Fixer rules, including NoLeadingSlashInGlobalNamespaceFixer, PhpdocNoSuperfluousParamFixer, NoUselessCommentFixer, NoTrailingCommaInSinglelineFixer, ForeachUseValueFixer, ClassConstantUsageFixer, and NoReferenceInFunctionDefinitionFixer. Some fixers are deprecated or risky, so review the README and fixer metadata before enabling them. Enable only the rules that match your team's coding standard.
- Are these custom fixers risky or can they change code behavior?
- PHP CS Fixer can mark fixers as risky, and some rules may alter semantics in edge cases, such as reference-related or comment-removal fixers. Always run php-cs-fixer fix --dry-run --diff first and review the patch on a branch. Start with low-risk, style-only rules and exclude risky ones until you have verified their output.
- How can I preview changes before applying the custom fixers?
- Run vendor/bin/php-cs-fixer fix --dry-run --diff with your config that registers and enables the custom fixers. This prints the proposed changes without writing files. Use a dedicated config file or rule list to limit the preview to only the custom fixers you are evaluating. Commit or discard the resulting fixer changes separately from functional work.
- Will this package affect my Laravel application at runtime or in production?
- No. It is a development dependency that runs only when PHP CS Fixer is executed, such as in local tooling, pre-commit hooks, or CI. It does not modify framework code at runtime and has no production performance impact. Keep it in require-dev and exclude vendor from fixer runs.
- How do I integrate these fixers into CI or a pre-commit hook?
- Install dev dependencies and run php-cs-fixer fix --dry-run --diff in CI to fail on style violations, or run php-cs-fixer fix to apply changes. For pre-commit, invoke the same command against staged files or the project paths. Add --allow-risky=yes only after you have reviewed and accepted the risky fixers you enable.
- How should I adopt these fixers in an existing legacy Laravel codebase?
- Create a baseline by running a dry run on a branch and measuring the diff before enabling rules broadly. Use path exclusions or ignore rules for generated code, migrations, or legacy areas that should not be reformatted yet. Enable a small set of high-value fixers first, commit formatting changes separately, and expand gradually.