Symfony Service Definition Validator Laravel Package

Product Decisions This Supports

• Build vs. buy vs. already-have: The core decision this package informs is whether to add a third-party dependency for dependency-injection (DI) validation or rely on the framework. On modern Symfony, the answer is “already have” — bin/console lint:container, CheckTypeDeclarationsPass, and debug:container cover the highest-value checks. This package is best treated as a reference point, not an adoption candidate.
• CI quality gate / shift-left on runtime failures: It frames the business case for catching “cannot autowire,” missing-service, wrong-argument-type, and unused-service defects at build time instead of in staging or production. That's a measurable reduction in deploy risk and incident load for large service graphs.
• Roadmap and upgrade planning: Useful input when scoping a Symfony 3.x/4.x → 5/6/7 upgrade, or when auditing a legacy monolith with hundreds of hand-written service definitions and compiler passes. The “unused service” and “missing service” style checks help size cleanup work.
• Framework applicability: It is Symfony-only and does not apply to Laravel's container. If the decision at hand is a Laravel stack, this package should be logged as out-of-scope; the analogous levers are Larastan, strict typing, and container-binding tests.
• Not a differentiator. At ~89 stars, a last release in February 2022, and a low health score, it does not support a “buy/partner” narrative or a claim of best-in-class tooling.

When to Consider This Package

Reasonable criteria:

• A Symfony application pinned below 4.4, where lint:container and declaration-type checks are unavailable in core.
• Heavy use of dynamic service definitions and compiler passes, where you specifically need the package's “unused definition” / “definition referenced but not defined” reporting that core commands don't fully replicate.
• Maintaining a third-party bundle and wanting an independent check that shipped service definitions are internally consistent.

Look elsewhere when:

• Symfony ≥ 4.4: enable lint:container in CI and add CheckTypeDeclarationsPass; zero new dependencies, first-party support.
• You want static analysis rather than container introspection: PHPStan/Psalm with the Symfony extension gives broader coverage and active maintenance.
• Your stack is Laravel: use framework-native tooling and Larastan; this package is inapplicable.
• Your security or dependency policy requires actively maintained releases. Last release February 2022 means no upstream fixes; adopting it creates a fork-and-own obligation. MIT licensing softens lock-in but doesn't remove the maintenance cost.
• You need guaranteed compatibility with current Symfony/PHP versions — unverified and unlikely to be tested against them.

How to Pitch It (Stakeholders)

For executives (one paragraph): DI misconfiguration is a class of defect that surfaces as production errors and emergency fixes, and it is almost entirely preventable. This package is a small, MIT-licensed, community tool that pioneered validating service wiring before deployment. However, the capability now ships with the framework, and the package itself has not been released since early 2022 and has limited adoption. Recommendation: adopt the practice, not the package — turn on the framework's built-in container linting in CI, keep the third-party dependency out of our stack, and revisit this package only if we inherit a legacy Symfony codebase that predates those checks.

For engineering:

• Add bin/console lint:container and the declaration-type check to the CI pipeline; fail the build on violations.
• Budget roughly one engineering day for rollout, plus a short burn-down list of pre-existing failures to fix or baseline.
• Add PHPStan with the Symfony extension for class-existence and type-signature coverage outside the container.
• Do not add matthiasnoback/symfony-service-definition-validator to composer.json for new work; if a specific legacy-only check proves necessary, vendor a fork under MIT with a named owner and a review date.
• Expected outcome: DI wiring errors caught in pull requests rather than at deploy, with no added supply-chain surface.