Coding Standard Bundle Laravel Package

Getting Started

1. Install as a dev dependency in your Symfony 7.0+ project:

   composer require --dev enabel/coding-standard-bundle
   

2. Register the bundle in config/bundles.php (if Flex didn't do it automatically):

   Enabel\CodingStandardBundle\EnabelCodingStandardBundle::class => ['dev' => true, 'test' => true],
   

3. Read the docs first — the entry point is docs/index.md in the repository. It is the canonical reference for the Makefile targets, Docker services, and default tool configuration. Skim README.md → docs/index.md → CHANGELOG.md in that order.
4. Check what tooling is now available. The bundle ships configuration and helpers for:
   • PHP-CS-Fixer (PSR-12 + Symfony rulesets)
   • PHPStan (Symfony, Doctrine, PHPUnit extensions)
   • Rector (Symfony, Doctrine, PHPUnit, Twig)
   • Linters for Twig, YAML, Symfony container, Symfony services, Doctrine mapping, Composer
   • A Makefile with targets wiring all of the above together
5. First use case — run a full lint pass on the project:

   make cs-check
   make phpstan
   make lint
   

   This is the fastest way to see what the bundle enforces and to decide which rules you want to keep, override, or baseline.
6. Bring up the Docker stack (MySQL, Redis, Mailcatcher) if you want local parity with CI:

   make up
   

Implementation Patterns

Make targets as the developer contract. The bundle’s value is that everyone runs the same commands. Treat the bundle’s targets (cs, cs-check, phpstan, rector, lint, test, up, down) as the project’s canonical entry points, and wire them into your own Makefile or a thin wrapper so local usage and CI invoke identical commands.

CI integration. In GitHub Actions (or GitLab CI), install with --dev, then call the same make targets. Because the bundle pins known-good configurations for PHPStan/Rector/CS-Fixer, you get reproducible results across local and CI without maintaining parallel phpstan.neon files.

Layered configuration. Keep the bundle’s defaults as the base and publish/override per-project config only where you genuinely diverge:

• phpstan.neon — add project-specific includes, custom rule extensions, and a baseline.neon for pre-existing violations so you can adopt the standard incrementally.
• .php-cs-fixer.dist.php — extend the bundle’s ruleset rather than replacing it; add project-specific rules on top.
• rector.php — start with the bundle’s rule sets and layer in per-upgrade paths when you take a Symfony/LTS bump.

Rector for upgrades, not routine commits. Use Rector dry-runs (--dry-run) in CI to preview changes, and apply real refactors in a dedicated branch during framework or PHP-version upgrades. This keeps Rector noise out of feature PRs.

Docker for dev-environment parity. Use the shipped Compose services (MySQL, Redis, Mailcatcher) so tests behave the same on every machine. Point DATABASE_URL, REDIS_URL, and MAILER_DSN at these services in .env.test / .env.dev.test and keep them out of production config.

Lint targets in pre-commit hooks. Add a small Husky/pre-commit hook that runs make cs-check and make lint (the fast linters) before commit, and leave PHPStan/Rector for CI or a pre-push hook — they’re heavier.

Container and service linters in CI only. The Symfony container/service and Doctrine linters need a bootable kernel, so run them after composer install on a clean checkout — don’t rely on them locally with a dirty cache.

Gotchas and Tips

• Version pinning matters. The bundle targets Symfony 7.0+. If a developer is on an older LTS, they’ll get dependency-resolution conflicts on install. Coordinate a Symfony version floor across the team before adopting.
• Config file collisions. If your project already ships phpstan.neon, .php-cs-fixer.dist.php, or rector.php, the bundle’s defaults may be silently ignored (or vice versa) depending on load order. Explicitly require/include the bundle’s config from your project files so the inheritance is visible in a diff.
• Makefile assumes make is installed. Windows devs without WSL/Git Bash will hit this. Either document the WSL prerequisite or expose equivalent Composer scripts (composer lint, composer stan) as fallbacks.
• Docker port conflicts. MySQL (3306), Redis (6379), and Mailcatcher (1025/1080) are common defaults — check for local services already bound to those ports before make up.
• PHPStan baseline drift. When you generate a baseline, commit it. Regenerating it silently after a dependency bump hides new violations.
• Rector needs a clean git tree first. Always run Rector on a clean working tree; otherwise a dry-run output is hard to distinguish from your own uncommitted edits.
• Cache invalidation. The Symfony container and service linters rely on a warm cache. If results look stale after config changes, clear with bin/console cache:clear (or make cc) before re-running.
• Extension points. Look in the bundle for documented extension hooks (custom rule registration, overriding linter skip paths, excluding directories from CS-Fixer). These are the escape hatches — prefer them over forking the configs.
• Debugging a lint failure. Most linter tools support -v / -vv; if a target doesn’t surface enough detail, run the underlying binary directly (e.g. vendor/bin/phpstan analyse -v) rather than through the make wrapper.
• Don’t require the bundle in production. It’s a dev tool — keep it in require-dev and guard the bundle registration with ['dev' => true, 'test' => true].