Coding Standard Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for developer tooling. Rather than spending engineering time assembling and maintaining a house standard (PHP-CS-Fixer rules, PHPStan baseline/config, Rector sets, Twig/YAML/container/Doctrine/Composer linters, a Makefile, and Docker services), this bundle packages that stack as a single dependency. The core PM decision it informs is "do we invest in our own tooling scaffolding, or adopt an opinionated off-the-shelf bundle?"
• Standardization and CI consistency. It directly supports a roadmap item like "uniform code quality gates across projects" by giving every repo the same linters and static analysis out of the box, which reduces per-repo drift and CI configuration churn.
• Onboarding and time-to-first-commit. Because it bundles Docker (MySQL, Redis, Mailcatcher) and a Makefile, it shortens the path from clone to a running, lint-clean environment—useful evidence for an "improve developer onboarding" initiative.
• Feature-level scope decisions. For a team deciding whether to add static analysis / Rector refactoring to the workflow, this is a low-effort way to trial those practices without committing to bespoke configuration.
• Platform/vendor strategy. With effectively no downstream dependents and a single-organization origin (Enabel), adopting it is a bet on a small, non-community-driven project. That is a risk-and-maintenance decision as much as a technical one, and should be weighed against rolling our own thin config package.
• Framework fit. Important scoping input: this is a Symfony 7.0+ bundle, not a Laravel package. It supports decisions about a Symfony-based service estate; it does not apply to Laravel applications, where equivalent tooling would be assembled separately.

When to Consider This Package

Consider it when:

• The codebase is Symfony 7.0+ and the team is comfortable with an opinionated, batteries-included quality stack.
• You want PHPStan + Rector + PHP-CS-Fixer + multi-linter coverage and local Docker/Makefile ergonomics without writing and maintaining the configs yourself.
• Your standards are close to the defaults (PSR-12, Symfony, Doctrine, PHPUnit, Twig) and you don't need deep customization of rule sets.
• You're standardizing a small portfolio of Symfony services and value uniformity over per-project tuning.
• You can accept the coupling and are prepared to pin versions and monitor upstream (it follows SemVer, has a changelog, docs, and releases, which helps).

Look elsewhere when:

• The stack is Laravel or framework-agnostic PHP—this bundle is Symfony-specific and not the right fit.
• You need a widely adopted, community-maintained standard with a large contributor base; this project has negligible downstream adoption and originates from a single organization.
• You require fine-grained control over static-analysis levels or custom rule sets that conflict with the bundle's opinions.
• You want to avoid a hard dependency on a low-adoption bundle in your build pipeline; a thin internal config package or direct dev-dependencies may be lower-risk.
• You're not on Symfony 7+, or you can't absorb the upgrade cadence as Symfony versions advance.

How to Pitch It (Stakeholders)

For executives: This is a developer-productivity bundle that installs a ready-made code-quality and local-environment toolchain into Symfony projects. The value proposition is straightforward: less time spent configuring linters, static analysis, and Docker per project, more consistent code review, and faster onboarding. If successful, it reduces tooling overhead and standardizes quality across services. The main caveat to flag is maintenance risk—this is a small, single-organization project with limited external adoption, so we should treat it as an internal-standard candidate rather than a strategic platform bet, pin versions, and be ready to fork or replace it. It applies only to our Symfony work, not Laravel.

For engineering: One dependency gives you PHP-CS-Fixer (PSR-12/Symfony), PHPStan (Symfony/Doctrine/PHPUnit), Rector (Symfony/Doctrine/PHPUnit/Twig), a linter suite (Twig, YAML, container, services, Doctrine, Composer), a Makefile, and Docker services (MySQL, Redis, Mailcatcher). It's opinionated by design, versioned with SemVer, and documented. Expect Symfony 7.0+ only, limited configurability against its defaults, and the need to track upstream for Symfony upgrades. Recommend a time-boxed pilot on one or two services, pin the version, and evaluate CI runtime and friction before rolling it out broadly.