Vanio Di Extra Bundle Laravel Package

Product Decisions This Supports

• Correcting the ecosystem assumption first. Despite being filed alongside Laravel packages, vanio/vanio-di-extra-bundle is a Symfony bundle, not a Laravel package. Any decision to evaluate it against a Laravel service-container problem is a category error — flag this before it consumes roadmap time. This is itself a useful portfolio-hygiene finding: it suggests the intake/cataloguing process is accepting packages without ecosystem validation.
• Build vs. buy vs. use-native. The realistic decision this package informs is "do we need a third-party DI extension layer at all?" Modern Symfony (4.4+, and certainly 5/6/7) ships autowiring, autoconfiguration, service attributes, and tagged-service handling that absorbed the core value proposition of the older "DI extra" bundle generation (the lineage that includes JMSDiExtraBundle). In most cases the answer is use the framework, not buy or build.
• Dependency-risk triage. With 0 stars, 0 dependents, and a composite score of 0.03, this is a do-not-adopt signal for greenfield work. A PM can use this as a concrete example in a vendor/dependency risk register and to justify a minimum bar (stars, dependents, release cadence, recent commits) for third-party inclusion.
• Legacy-modernization scoping. The genuine use case is a pre-existing Symfony application already wired to this bundle's conventions. There, the PM decision is a migration decision: quantify the annotation/attribute-based service definitions in use, estimate the cost of converting to native autowiring, and sequence it against other platform work.
• Roadmap prioritization input. Opportunity score of ~21 is a weak-but-nonzero signal; it is not a reason to allocate engineering capacity. Treat it as background context, not a candidate initiative.

When to Consider This Package

Consider it only in narrow circumstances:

• You are maintaining an existing Symfony application that already depends on it, and removing it is a larger change than keeping it for one more release cycle.
• You are on an older Symfony version where native autowiring/attributes do not cover your service-definition patterns, and you need convention-over-configuration service registration without writing a custom compiler pass.
• You need a short-lived bridge during a migration and are willing to vendor/fork the code internally, accepting full maintenance ownership.

Look elsewhere — or do nothing — when:

• You are on Symfony 4.4+ and native autowiring, autoconfiguration, and PHP attributes already solve the problem. This is the overwhelmingly likely case.
• You are building on Laravel; the Laravel service container, contextual binding, and package discovery operate on entirely different conventions. There is no integration here.
• You need active maintenance, security patching, or community support. Zero stars and zero dependents means effectively no upstream user base to surface bugs and no realistic expectation of timely fixes.
• You are standardizing a new service or a greenfield codebase — the cost of an extra abstraction layer exceeds its benefit at this maturity level.
• Your organization has dependency admission criteria (maintained releases, transitive-dependency hygiene, license review beyond MIT). MIT licensing is a point in its favor; the maintenance profile is not.

How to Pitch It (Stakeholders)

For executives: We evaluated a third-party dependency-injection add-on that surfaced in our package intake. Two findings matter. First, it is a Symfony component, not a Laravel one, so it is out of scope for our Laravel services — a cataloguing issue worth tightening. Second, it has no meaningful adoption (no dependents, no community, no observable maintenance signal) and its core functionality has been subsumed by the framework itself. Recommendation: do not adopt; no roadmap impact; no budget requested. If it already exists in a legacy Symfony codebase, we should log it as technical debt and size a migration to native autowiring.

For engineering: The value proposition — convention-based service registration and annotation/attribute-driven DI — is largely redundant on Symfony 4.4+. Native autowiring, autoconfiguration, and tagged services cover the common cases, and the attribute-based approach is now first-class. Adopting this bundle adds an abstraction layer with no upstream maintainer to patch it. If a legacy service depends on it, plan a conversion to native configuration; if a team believes they need it, ask them to demonstrate which native capability is insufficient before we accept the dependency.