Bundle Dependency Laravel Package

Product Decisions This Supports

• Build vs. buy for bundle registration tooling. This package is a candidate "buy" (adopt off-the-shelf) answer to a recurring internal problem: implicit ordering constraints between Symfony bundles. Adopting it avoids writing a bespoke topological-sort layer into AppKernel/bundles.php.
• Roadmap: dependency hygiene and upgrade readiness. If we are planning a Symfony version migration or a modularization/monolith-splitting effort, this package surfaces the dependency graph we would otherwise have to reconstruct manually. It is useful as a discovery instrument before committing to a migration plan.
• Reducing integration and onboarding friction. In large, bundle-heavy applications, "bundle X must load before Y" knowledge often lives in one engineer's head. Declaring dependencies on the bundle class converts tribal knowledge into machine-checked configuration, which lowers onboarding cost for new engineers and shortens time-to-first-PR.
• Engineering productivity and defect prevention. Missing and circular dependency detection turns a class of late, hard-to-diagnose runtime failures into early, explicit errors. That is a measurable reduction in debugging time per incident, even if small per occurrence.
• Use-case fit: multi-bundle applications. Best value where we own or maintain several bundles with real ordering constraints. Low value in applications with a handful of bundles or where Symfony Flex already gives us a deterministic, explicit bundles.php.
• Technical due diligence on legacy portfolio. For inherited Symfony 2/3-era codebases, this is a cheap probe to quantify how tangled the bundle graph is, which informs whether to refactor, freeze, or rebuild.
• Vendor-risk scoring. The signals here (19 stars, last release February 2018, low adoption score) argue against treating this as a long-term strategic dependency. The decision it should drive is "evaluate, possibly vendor/fork for a legacy codebase," not "standardize on it."

Note on platform fit: despite the framing, this is a Symfony package, not Laravel. Laravel's equivalent surface is service providers and register()/boot() ordering, which this package does not address. Any Laravel roadmap item must be assessed separately; this package should be scoped to Symfony workstreams only.

When to Consider This Package

Consider adoption when:

• The application is Symfony 2.x/3.x-era (or a Symfony 4+ app still carrying many legacy bundles) and its bundle registration order is a known source of defects.
• We maintain multiple internal bundles with real, non-obvious ordering requirements, and those requirements are currently undocumented or enforced by convention.
• We have seen repeated "service not found," "class not found," or wiring failures at boot that trace back to registration order, or genuine circular bundle dependencies.
• We want the dependency graph to be declared and reviewable in code, so it can be validated in CI rather than discovered in production.
• We have the appetite to vendor or fork a small, MIT-licensed utility and take ownership of it — the code surface is modest and the problem is well understood.

Look elsewhere when:

• The platform is Laravel or another framework; the bundle/AppKernel model does not apply.
• The application is modern Symfony using Flex, where config/bundles.php is already an explicit, ordered, version-controlled manifest and the added abstraction buys little.
• The bundle count is small (roughly under ten) and ordering is obvious from the file itself.
• We require active maintenance, PHP 8+ support, security patching, or a support agreement — the 2018 last release makes this unsuitable as a critical-path dependency without a fork-and-own plan.
• The team lacks capacity to own a fork, or the org has a policy against unmaintained third-party dependencies.
• Ordering problems are actually service-container configuration problems; the correct fix is compiler passes and service definitions, not bundle sequencing.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a small, MIT-licensed utility that makes Symfony bundle load order explicit and self-checking instead of manual and error-prone. The upside is concrete but bounded: fewer boot-time integration failures and a machine-readable map of how our bundles depend on each other, which is directly useful if we pursue a Symfony upgrade or modularization. The risk is equally concrete: the project has been unmaintained since 2018, has minimal adoption, and would become our code to support. My recommendation is therefore not to adopt it as a strategic platform dependency, but to treat it as a low-cost diagnostic and, at most, an internally forked utility for legacy bundle-heavy applications — a narrow, reversible bet rather than a roadmap commitment.

For engineering leads: The mechanism is a topological sort over bundle dependencies declared on each bundle class, with explicit errors for missing and circular dependencies, integrated into existing registration workflows. It replaces convention-based ordering with a validated graph and gives us a cheap way to measure coupling in inherited codebases. The implementation is small enough to audit in an afternoon. The tradeoffs are staleness (PHP/Symfony version compatibility must be verified before any use), no upstream support, and the likelihood that a fork is required. If we proceed, scope it to a spike on one legacy application, verify compatibility and test coverage against our Symfony version, and make the fork-or-drop call on that evidence.