Composer Dependency List Bundle Laravel Package

Getting Started

This bundle is a thin Symfony integration around the frostiede/composer-dependency-list library: it gives you a console command that walks your installed Composer packages and prints their dependency relationships. It is a CLI/inspection tool, not a runtime feature, so the setup cost is deliberately low.

1. Install it as a dev dependency — there is no reason for it to ship to production:

   composer require --dev frostiede/composer-dependency-list-bundle
   

2. Register the bundle. With Symfony Flex the recipe (if present) adds it automatically; otherwise add it manually to config/bundles.php:

   FrostieDE\ComposerDependencyListBundle\ComposerDependencyListBundle::class => ['dev' => true, 'test' => true],
   

3. Discover the exact command name and options rather than guessing — the bundle is low-adoption (0 stars, 0 dependents), so don't assume a familiar verb:

   php bin/console list composer
   php bin/console <command> --help
   

4. First use case: before bumping a shared internal package, answer "what is the blast radius?" Run the command for that package and read off the direct and transitive dependents. That single query — which normally means grepping composer.lock by hand — is the whole value proposition.

Where to look first: vendor/frostiede/composer-dependency-list-bundle/ for the command class (it tells you exactly which output format and which underlying library method is used), and vendor/frostiede/composer-dependency-list/ for the parsing logic. Those two directories answer almost every question you'll have.

Implementation Patterns

Upgrade blast-radius checks. The dominant workflow. Before composer update vendor/pkg, list its dependents, then diff that list against the same list from main. If the dependent set grew, you know the upgrade touches more of the tree than the changelog suggests. Capture the output to a file in CI artifacts so upgrade PRs carry the evidence.

Reverse-dependency lookup for removals. When deciding whether a package is dead weight, the dependent list answers "does anything still pull this in?" faster than composer why. Wire it into a make dead-deps target and run it quarterly — this is the pattern that pays for the tool's install cost over a year.

CI drift gate. A cheap job that asserts the dependency graph for a small set of critical packages matches a committed snapshot:

php bin/console <command> --package=acme/core > var/deps.txt
diff -u .ci/deps-baseline.txt var/deps.txt

Regenerate the baseline in the same PR that legitimately changes the graph. This catches accidental transitive creep (a dependency you don't directly declare) far earlier than a security audit does.

Scripted reporting. Because this is a console command, treat it as a subprocess, not an API: run it with Symfony\Component\Process\Process from a maintenance command, or shell out from a scheduled task, and pipe to jq if the output is structured. If you need the data inside PHP repeatedly, prefer calling the underlying frostiede/composer-dependency-list library directly and skip the command layer entirely.

Composition with native Composer tooling. This bundle overlaps with composer why, composer why-not, and composer depends. The distinction worth adopting: Composer answers questions about constraints and resolution, this tool answers questions about what is actually installed in this lock file. Use it after composer install, not instead of composer why-not when debugging a conflict.

Local dev convenience. For teams that constantly ask "who pulls in X," add a thin Makefile alias with a sane default package argument, so the invocation is muscle memory rather than a --help expedition each time.

Gotchas and Tips

• It reads installed state, not the constraint graph. Results reflect composer.lock / vendor, so a stale lock or a partial composer install yields misleading answers. Make composer install a hard prerequisite of any scripted use.
• Verify dev-dependency handling explicitly. Whether require-dev edges appear is a per-tool decision, and getting it wrong silently changes your blast-radius answer for dev tooling packages. Test once with a package you only pull in via require-dev and record the behavior in your team docs.
• Don't parse human-readable output on a hot path. With zero dependents and a 0.x-style maturity profile, output formatting is not a stable contract. If you must parse, pin the exact version in composer.json and treat a bump as a breaking change requiring a test run.
• Pin it and isolate it. This is require-dev-only, single-maintainer territory. Constrain the version (^x.y), and if you build anything load-bearing on top of it, wrap that in your own one-method service so a swap to the underlying library or to native Composer commands is a one-file change.
• Large graphs cost time and memory. Big monorepo vendor/ trees make the traversal slow. If a CI job times out, scope the command to a specific package rather than dumping the whole graph.
• Register the bundle in dev/test only. Registering it in prod is harmless but pointless, and it makes prod bundle lists noisier for no gain.
• Extension point: decorate, don't fork. If you need custom filtering or a JSON shape tailored to your dashboards, decorate the bundle's command service or write your own command around the library. Forking a 0-star package is a maintenance trap.
• Debugging first move: if the command errors on boot, it's almost always bundle registration or the console kernel's cache. bin/console cache:clear then bin/console list disambiguates in seconds.
• Check the PHP/Symfony constraints before adopting. A low-adoption bundle is often a release or two behind current Symfony majors; confirm compatibility against your minimum supported version rather than assuming Flex will sort it out.