Coding Standard Bundle Laravel Package

Technical Evaluation

Architecture fit. The first thing a TPM must correct is the framing: this is not a Laravel package. enabel/coding-standard-bundle is a Symfony bundle targeting Symfony 7.0+, and it is a development-time dependency, not a runtime library. Its value is consolidation: it packages opinionated configurations and helpers for PHP-CS-Fixer (PSR-12 + Symfony rules), PHPStan (Symfony/Doctrine/PHPUnit extensions), Rector (Symfony/Doctrine/PHPUnit/Twig), a linter suite (Twig, YAML, Symfony container, Symfony services, Doctrine, Composer), a Makefile, and a Docker composition (MySQL, Redis, Mailcatcher). In architectural terms it is a developer-experience (DevEx) bundle that standardizes the quality gate rather than the application. It fits organizations running a portfolio of Symfony services that want a single golden path for static analysis, formatting, and local environment; it does not fit Laravel shops, and it does not add runtime capability.

Integration feasibility. Integration is mechanically simple — composer require --dev enabel/coding-standard-bundle, wire the provided configs, and adopt the Makefile/Docker targets if desired. The real work is not installation but reconciliation: comparing the bundle's pinned tool versions and rule sets against whatever each project already runs. Feasibility is high for greenfield Symfony 7 services and medium for brownfield projects with established PHPStan baselines and Rector sets, where adoption means resolving a delta of new findings. Because the Docker composition assumes MySQL/Redis/Mailcatcher, projects on PostgreSQL or different brokers get partial value only.

Technical risk.

• Ecosystem mismatch (highest). If the consuming portfolio is Laravel-first, this package is effectively unusable beyond copy-pasting config ideas.
• Version coupling. The bundle pins or constrains major versions of PHPStan, Rector, PHP-CS-Fixer, and the Symfony linters. Those tools ship breaking majors frequently; a slow bundle release cadence can block a project from upgrading PHPStan independently.
• Adoption signal. Zero dependents and a low star count mean this is a vendor-internal standard published publicly, not a battle-tested community artifact. Expect Enabel's conventions, not universal ones.
• Opinionation risk. Coding standards are political. Adopting the bundle transfers rule ownership to a third party; any deviation requires local overrides, which erodes the "one standard" benefit.
• Governance. Single-organization maintenance with no SLA or published support model; the MIT license permits forking, which is the practical mitigation.

Key questions.

1. Is our portfolio Symfony 7+ or Laravel-dominant, and what percentage of services would actually consume this?
2. Does the bundle's rule set match our existing standards, or does it require us to concede on formatting/strictness?
3. How quickly does the maintainer track upstream majors of PHPStan/Rector/PHP-CS-Fixer, and can we override constraints without forking?
4. What is the intended consumption model — as a bundle, as a Composer-installed dev dependency, or as a template/reference for our own coding-standard package?
5. Do we have a DevEx/platform team to own the golden path if the upstream goes quiet?
6. Is the Docker composition compatible with our infrastructure standards, or is it only useful as documentation?

Integration Approach

Stack fit. Prerequisites are PHP 8.2+ (implied by Symfony 7), Composer 2, and Symfony 7.0+. Best fit: a platform or DevEx team standardizing CI and local tooling across multiple Symfony services. Marginal fit: a single Symfony app that already has hand-rolled configs — the ROI is smaller than for a portfolio. No fit: Laravel or non-Symfony PHP estates; treat the repository as a reference implementation of a quality baseline rather than a dependency.

Migration path. Do not roll out fleet-wide on day one.

1. Inventory existing phpstan.neon, .php-cs-fixer.php, rector.php, .twig-lint, Makefile, and docker-compose.yml files across services and diff them against the bundle's defaults. This diff is the business case: quantify duplicated config lines and divergent rule versions.
2. Pilot on one low-risk service (ideally greenfield or a small internal tool). Install as a dev dependency, adopt the configs via require/imports rather than wholesale replacement, and run the full linter suite in CI in non-blocking mode first.
3. Measure the finding delta: how many new PHPStan/Rector violations surface. That number drives the effort estimate and the decision to use baselines versus fixing forward.
4. Ratify the rule set with engineering leadership — this is a policy decision, not an infrastructure one. Publish an ADR recording which rules are adopted, overridden, or deferred.
5. Template the result (Composer metapackage or a project skeleton) so new services inherit the standard by default.
6. Broaden repo by repo, blocking CI only after baselines are clean.

Compatibility. Maintain an explicit compatibility matrix — bundle version × Symfony version × PHP version × PHPStan/Rector major — and test it in a matrix CI job if you own the template. Verify that your projects can override tool constraints in root composer.json without conflict; if the bundle hard-pins, plan for replace/fork. Note the SemVer promise: minor upgrades should be safe, but tool-config defaults changing inside a minor is a realistic disruption vector, so pin the bundle version and upgrade deliberately.

Sequencing. Config-only adoption first (PHP-CS-Fixer, linters — low blast radius), then Rector (mechanical but rewrites code), then PHPStan at increasing levels, and only then the Makefile/Docker conventions, which are the most environment-specific and lowest-value components. If the Laravel question is unresolved, sequence a spike to extract the configurations into your own package before committing to the dependency.

Operational Impact

Maintenance. Net maintenance should decrease — one dependency and one upgrade cadence replacing N hand-maintained config files per repository. The offsetting cost is a new external upgrade obligation and the work of authoring overrides wherever the bundle's opinions diverge from ours. Budget a recurring, small per-quarter effort for version bumps, and a larger one-time reconciliation cost during adoption. If we fork or wrap, that becomes a permanent, owned maintenance line — account for it explicitly.

Support. No commercial support, no SLA, no published deprecation policy beyond SemVer and a changelog. Responses depend on a small maintainer group's goodwill and GitHub issue throughput. For a production CI dependency this is acceptable only if we retain the ability to fork under MIT and have internal expertise to do so — a static-analysis config bundle is low-risk to own, unlike a runtime library. Assign a named internal owner regardless.

Scaling. This scales well organizationally: it is the classic "paved road" pattern, and value grows with the number of services rather than with request volume. Two scaling constraints: (a) heterogeneity — the moment services diverge to Laravel, older Symfony versions, or non-Docker local setups, coverage fragments; (b) centralization risk — a single bad release propagates to every repository at once, so roll out via pinned versions and a canary service.

Failure modes.

• Upstream stagnation: bundle lags upstream tool majors, blocking project-level upgrades. Mitigation: monitor, fork, or vendor the configs.
• CI breakage cascade: a bundle release changes rule defaults and turns every pipeline red simultaneously. Mitigation: pin, canary, staged rollout.
• Override sprawl: projects accumulate local config overrides until "the standard" is nominal. Mitigation: audit overrides quarterly; anything repeated twice belongs upstream or in our wrapper.
• Environment lock-in: Docker composition and Makefile targets assume MySQL/Redis/Mailcatcher and a GNU Make toolchain. Mitigation: treat as optional components.
• Silent drift: developers disable linters locally to move fast, so CI is the only real gate. Mitigation: enforce in CI, not in pre-commit hooks alone.
• Bus factor: maintainer unavailability halts fixes. Mitigation: fork readiness documented in the ADR.

Ramp-up. Low for engineers — the tools (PHPStan, PHP-CS-Fixer, Rector) are industry standard and the bundle only supplies configuration, so the learning curve is mostly "learn the rules," not "learn a framework." Expect roughly half a day for a senior engineer to adopt on a clean service, and one to three days on a mature service with existing baselines and accumulated violations. The larger ramp-up is organizational: getting teams to accept a shared standard and to stop negotiating per-repo rules. The docs/README/CHANGELOG present is sufficient to start but thin on override patterns and upgrade notes — a TPM should plan for an internal runbook rather than relying on upstream documentation.

Bottom line for the portfolio. High-leverage, low-blast-radius dependency for a Symfony 7+ estate with several services and an owner for developer tooling; a poor fit and a likely distraction for a Laravel-centric or single-service estate, where the correct move is to harvest its configurations into our own standard rather than take the dependency.