Injection Bundle Laravel Package

Product Decisions This Supports

• Framework-fit gate, and a rejection of the intake framing. Despite being requested as a "Laravel/PHP package," incompass/injection-bundle is a Symfony bundle — it hooks into Symfony's Bundle/Kernel and container-compiler-pass lifecycle. It has no Laravel service provider, no config publishing, and no Laravel container integration. If our stack is Laravel, this is disqualified before any cost/benefit analysis begins. This is a useful signal on its own: it means our package-intake request was mis-scoped, and we should tighten the "framework compatibility" field required before a package reaches a PM.

• Build vs. buy vs. configure — resolved as "configure." The pain it addresses (declaring injection targets via annotations instead of XML/YAML service definitions) was real around Symfony 2.x. It's now solved natively: autowiring and autoconfigure (3.3+), and PHP 8 attributes — #[Autowire], #[Required], #[TaggedIterator], #[AsDecorator] (6.1+). The build/buy decision resolves to "buy nothing, build nothing, use the framework we already pay for." On Laravel, constructor injection plus contextual binding already delivers the same ergonomics.

• Vendor/supply-chain risk scoring. Zero stars, zero dependents, no release cadence, no visible security-response process, and a single non-tooling vendor (Incompass, a CRM vendor). A dependency-injection extension sits under every service in the container, so the blast radius is the entire application. This fails any reasonable third-party risk threshold — the kind of thing we'd want caught automatically before it reaches a roadmap conversation.

• Roadmap opportunity cost. Adopting an alternate DI mechanism is a cross-cutting architectural commitment, not a feature. Every future service would route through a non-standard path, onboarding gets taxed, static analysis and IDE navigation degrade, and new hires will still wire services the framework-native way — producing two competing DI styles in one codebase. High blast radius, near-zero marginal value.

• Migration triage for inherited code. If this surfaces in an acquired or legacy Incompass-based codebase, it supports a contain-and-replace-at-next-major decision — pin the version, isolate it to the legacy module, schedule removal — rather than a standardize-on-it decision.

When to Consider This Package

Consider it only if all of the following hold:

• You are on Symfony, not Laravel — the bundle cannot function in a Laravel application.
• You are pinned to a pre-autowiring Symfony version (<3.3), or are otherwise architecturally committed to annotation-driven service configuration.
• You have an existing Incompass codebase already depending on it, where the cost of ripping it out exceeds the cost of vendoring and self-maintaining a fork.
• You have confirmed license terms, source availability, and a real release, and are prepared to own the code — assume zero upstream support.

Look elsewhere / do not adopt if:

• You're on Laravel (which the request framing implies). Incompatible. Use constructor injection, contextual binding, and the framework container — already equivalent or better.
• You're on Symfony 4+/5/6/7. Native autowiring plus PHP 8 attributes subsume the feature set with better tooling, type safety, and core-team backing.
• You require maintained dependencies. Zero dependents and no release history is disqualifying for anything entering a shared service container.
• You care about static analysis or developer experience. Native attributes are far better supported by PHPStan/Psalm and IDEs than third-party annotation parsing; annotation-based DI also drags in doctrine/annotations, which is in maintenance mode.

How to Pitch It (Stakeholders)

Recommendation: reject. Do not adopt, do not POC, do not procure.

This is a Symfony-only, zero-adoption bundle that adds annotation-based dependency injection — a capability Symfony has shipped natively for years via autowiring and PHP 8 attributes (#[Autowire], #[Required], #[TaggedIterator]), and that Laravel already provides through its container and constructor injection. It has no measurable community (0 stars, 0 dependents), a single non-tooling vendor, unverified license and version constraints, and no visible maintenance or security-response signal. Because DI configuration touches every service in the container, the downside risk is application-wide while the upside is a small syntactic convenience we already get for free.

For engineering: the in-framework equivalents are type-safe, statically analyzable, IDE-navigable, and maintained by the framework's core team. If our stack is Laravel, the package is simply incompatible — there is no shim that loads a Symfony bundle into a Laravel application. If anyone proposes porting its annotation-scanning into a service provider, that is a rewrite with added reflection cost and a bespoke convention no hire will recognize; decline it. If the target system is genuinely legacy Symfony, map each annotation to its modern equivalent (@Inject → constructor type-hint autowiring; setter/method injection → explicit calls or a compiler pass) and budget it as a small refactor inside the port, not as a dependency decision.

Action: close the evaluation. Fix the intake record so this is filed as Symfony-only. If the dependency is found in inherited code, log it as technical debt — pin the version, contain it to the legacy module, and scope replacement into the next major version rather than expanding on it.