Weave Code
Bundle Dependency Laravel Package
symfony-bundles/bundle-dependency
A Symfony bundle for managing dependencies between bundles. Declare required bundles and let the package verify installation and loading order, helping modular Symfony applications avoid missing or misordered dependencies.
Symfony Bundle Dependency Component
Frequently asked questions about Bundle Dependency
- What is symfony-bundles/bundle-dependency used for?
- It lets Symfony bundles declare explicit dependencies on other bundles and resolves the order in which they are registered, so a bundle that relies on another is loaded after it. It also detects missing and circular dependencies early during application bootstrapping. It targets modular Symfony applications with complex bundle setups rather than Laravel applications.
- Does symfony-bundles/bundle-dependency work with Laravel?
- No. The package is Symfony-only: it hooks Symfony's bundle registration lifecycle, including bundles.php and Kernel::registerBundles(), and builds a dependency graph over Symfony Bundle subclasses. Laravel has no bundle concept; it uses service providers, the config/app.php provider list and package discovery via extra.laravel.providers. For Laravel, provider ordering is usually better handled with register() versus boot() discipline and deferred providers than with a third-party graph resolver.
- Which Symfony and PHP versions does this bundle support?
- The last release was February 2018, so the codebase targets the PHP 7.x and Symfony 3.x/4.x era. There is no published guarantee of PHP 8.x compatibility or support for Symfony 5, 6 or 7, whose kernel and bundle metadata contracts changed. Treat newer versions as unsupported until you verify compatibility with your own test suite.
- How do I install and wire up bundle-dependency in a Symfony app?
- Install it with Composer and then take ownership of the bundle registration path, typically with a custom Kernel::registerBundles() or an AppKernel subclass that consults the resolver before returning the bundle list. It is not a drop-in library, and a mistake there stops the application from booting at all. Isolate the change and test the boot path thoroughly before merging.
- How does it detect missing or circular bundle dependencies?
- The package resolves a dependency graph over declared bundle requirements and reports a missing dependency when a required bundle is not registered. A cycle appears when ordering cannot be satisfied because bundles depend on each other transitively. Detection happens during bundle registration, so problems surface at boot rather than at runtime.
- Can I declare a dependency on a third-party bundle I do not control?
- Generally no, or only awkwardly: dependencies can only be declared on bundle classes you control, so a vendor bundle cannot be annotated without subclassing or forking it. That makes the resolver's graph structurally incomplete exactly where implicit ordering constraints usually live. If most of your ordering problems involve third-party bundles, this package cannot express them.
- Is symfony-bundles/bundle-dependency maintained and safe for production?
- The project's last release was February 2018, with a small star count and a repository listed as unknown, which fits an abandoned hobby utility rather than a foundation dependency. There is no evident security disclosure process or CVE tracking, and it is single-maintainer code with no successor. Putting unmaintained code in your application's boot path is a high-risk placement for abandonment risk.
- What is a simpler alternative to adopting this package?
- The real value here is a topological sort with cycle detection, which is a small amount of MIT-licensed logic you can reimplement in roughly a hundred lines. Vendoring that logic into an internal kernel helper keeps the benefit without adopting an abandoned dependency. Modern Symfony's explicit bundles.php array also reduced the ordering problem compared with the Symfony 2/3 era.
- How does it interact with Symfony Flex and bundles.php?
- Symfony Flex manages bundles.php as an explicit array, which already gives a deterministic, reviewable registration order for a typical 10 to 20 bundle application. bundle-dependency predates that workflow and assumes it can influence registration order itself. Using it means owning the kernel wrapper that reads the bundle list and applies the resolver on top.
- Should I use it in a Laravel app to order service providers?
- No. Laravel service provider order is controlled by config/app.php and package discovery via extra.laravel.providers, and ordering issues are usually design problems solved with register() versus boot() discipline or deferred providers. There is zero code reuse between this Symfony bundle and a Laravel stack. For a Laravel initiative, decline this package and close the ticket.
Weaver
How can I help you explore Laravel packages today?