- How do I install romanzipp/php-cs-fixer-config?
- Install it as a dev dependency with composer require --dev romanzipp/php-cs-fixer-config. Then wire the provided config object or rules array into your project's .php-cs-fixer.php, which is roughly three lines of integration. There is no service provider or artisan command because this is a config-only package. Check the package's composer.json to confirm which PHP-CS-Fixer version it expects before running the fixer.
- Does this package work with Laravel projects?
- It is framework-agnostic and has no Laravel-specific integration, service provider, or Blade or Eloquent awareness. It only supplies a PHP-CS-Fixer ruleset that can be used in the static-analysis layer of any PHP project, including Laravel. In a modern Laravel repository, however, Laravel Pint already bundles PHP-CS-Fixer with a Laravel-blessed preset, so this package competes directly with that default.
- Is romanzipp/php-cs-fixer-config compatible with Laravel Pint?
- Pint bundles PHP-CS-Fixer with its own preset, so adding this package creates a second formatter with potentially overlapping CI jobs and pre-commit hooks. You should pick one enforcement layer rather than running both. If you want these rules, translate the rules array into a custom Pint preset via pint.json instead of depending on the package alongside Pint.
- Which PHP-CS-Fixer version does this package support?
- The package is a personal ruleset and the overview does not state a compatibility contract, so inspect its composer.json to see whether it declares a PHP-CS-Fixer constraint or assumes one. Its last release was 2021-08-06, which predates newer fixer releases and PHP 8.2 and 8.3 rule awareness. Assume rule drift and run a manual audit rather than trusting the output blindly.
- Is romanzipp/php-cs-fixer-config still maintained?
- Signals are weak: the last release was 2021-08-06, the repository has about 5 stars and 0 dependents, and the ruleset reflects one maintainer's preferences. There have been no updates for newer PHP versions, deprecation handling, or PHP-CS-Fixer major version bumps. The MIT license means you can fork or vendor the rules without restriction, which is often the safer path.
- How do I use the ruleset inside my .php-cs-fixer.php file?
- Require the Composer autoloader, then return the package's config object or merge its rules array into your own PhpCsFixer\Config instance. The exact shape matters because a class-based config is more coupled to fixer internals than a raw array. Review the source to confirm whether it exposes a class, a function, or a plain rules array before integrating it.
- What ruleset baseline does this config extend?
- The overview does not specify whether it extends @PSR12, @Symfony, or a fully custom rule set, so read the source before adopting it. That baseline determines how opinionated the output is and how much churn it will cause against your current formatting. If it extends a broad preset, expect the differences to be mostly individual rule overrides rather than a complete style philosophy.
- Should I depend on this package or vendor the rules into my own project?
- Vendoring is the recommended path: copy the rules array into an internal file such as tools/php-cs-fixer/rules.php or translate it into a custom Pint preset. This preserves whatever value the ruleset has while eliminating abandonment and PHP-CS-Fixer version compatibility risk. The MIT license makes copying unambiguously legal, and the migration cost if the package dies is near zero anyway.
- Does this package add runtime or security risk to a Laravel application?
- No runtime surface is exposed because it is a dev-only tooling dependency with no service provider, HTTP routes, database footprint, or application code. Security risk is negligible, and the transitive attack surface is minimal for a config-only dev package. The real risk is technical maintenance drift, not runtime exposure.
- How should I roll out this ruleset safely in an existing codebase?
- Run the package's ruleset with --dry-run --diff on a throwaway branch and compare the output against your current Pint or fixer results to quantify churn. If the diff is large, use a baseline commit or --set-baseline so you do not open a 400-file formatting pull request that blocks the team. Then land CI enforcement with --dry-run and decide whether to vendor the rules or discard them.