Php Cs Fixer Config Laravel Package

Getting Started

Add the package as a dev dependency to your project:

composer require --dev oscarotero/php-cs-fixer-config

Then, in your .php-cs-fixer.php config file (root of your project), require and use the provided config:

<?php

return (require_once 'vendor/oscarotero/php-cs-fixer-config/config.php')();

That’s it — you immediately get a consistent, opinionated ruleset without defining any rules manually. Run ./vendor/bin/php-cs-fixer fix to format your codebase.

Implementation Patterns

• Shared team config: Pin the package version in composer.json to lock the style guide. Update via PR to ensure controlled evolution of rules.
• Monorepo consistency: In shared monorepos or microservices, each service can use the same config file via relative path or symlink, guaranteeing identical formatting across all repositories.
• CI integration: Add a lint step that runs php-cs-fixer check --dry-run to fail CI if non-conforming code is introduced.
• IDE integration: Configure your IDE (e.g., PHPStorm) to use .php-cs-fixer.php as the config for auto-formatting — the config’s presence ensures consistency with CI.
• Override selectively: If needed, extend the config locally by merging in custom rules after the require:

  $config = (require_once 'vendor/oscarotero/php-cs-fixer-config/config.php')();
  $config['rules']['my_custom_rule'] = true;
  return $config;
  

Gotchas and Tips

• Version pinning is critical: Since rules may change in new releases, always lock the package version (e.g., ^1.2) and update deliberately — review changelog before upgrading.
• Cache stale after upgrade: If formatting behaves unexpectedly after an upgrade, clear PHP-CS-Fixer’s cache (rm -rf ~/.cache/php-cs-fixer/) — old rules can linger.
• CI environment quirks: In Docker or minimal CI images, ensure ext-fileinfo and ext-tokenizer are installed; missing extensions can cause silent failures.
• Not all rules are configurable by default: The package ships with a fixed ruleset — if your project requires highly specific tuning (e.g., disabling braces for legacy compatibility), you’ll need to override per project, accepting the trade-off of losing centralization.
• Autoloading conflict: Avoid requiring the config file multiple times (e.g., in tests or custom tools); wrap the require in __DIR__ . '/vendor/oscarotero/...' to ensure uniqueness and avoid fatal redeclaration errors.