Product Decisions This Supports
- Dependency hygiene / tech-debt prioritization: Produces an evidence-based list of Composer packages that no longer appear in the codebase, giving you a defensible rank-order for cleanup work instead of guesswork. Useful input to sprint planning when a "reduce dependencies" epic needs scoping.
- Security posture and attack-surface reduction: Every unused package is still installed, autoloaded, and (usually) still shipped to production. Removing them directly shrinks the CVE surface, the SBOM, and the noise in vulnerability alerts — an easy, low-risk win to cite in security reviews.
- Build vs. buy for internal tooling: If the alternative is writing a bespoke AST/regex scanner in-house, this package (MIT, 425 stars) is a cheap evaluation candidate. It is a build-vs-buy decision with almost no procurement cost and a small, contained blast radius if abandoned.
- CI/build performance and image size: Unused dependencies inflate vendor/ size, container layers, and cold-start times. Justifies a dependency-budget initiative with measurable before/after metrics (image MB, CI minutes).
- License and compliance inventory: Pruning unused packages simplifies license reporting and reduces the number of third-party terms legal must review.
- Due diligence / handover audits: A fast way to characterize the health of an inherited Laravel codebase — "N of M declared dependencies are unreferenced" is a concrete, quantified finding for acquisition or takeover assessments.
- Roadmap input for framework upgrades: Before a Laravel/PHP major-version upgrade, this identifies which dependencies you can drop rather than port, reducing migration scope and risk.
When to Consider This Package
- Legacy or long-lived Laravel monoliths where
composer.json has accreted packages over years and nobody remembers why half of them are there.
- Pre-audit sweeps ahead of a security review, SOC2-style assessment, acquisition diligence, or a major framework upgrade — where you want a cheap first pass before spending on deeper analysis.
- Post-refactor cleanup: after removing a feature area (payments provider, old queue system, deprecated API client), confirm the related packages can actually be dropped.
- You need a one-off report, not a permanent platform: treat it as a diagnostic run, not a critical CI dependency.
- Look elsewhere if:
- The codebase relies heavily on dynamic resolution — string-based class names, container bindings resolved by config, Blade/JSON-driven references, Laravel package auto-discovery, or event/listener conventions. Expect false "unused" positives that need manual verification before deleting anything.
- You need actively maintained tooling. The last release here is 2022-01-05 — roughly four years stale. Verify compatibility with your current PHP and Composer versions before adopting; no fixes should be assumed for newer Composer 2.x autoload formats or PHP 8.2+ syntax.
- You want deeper static analysis as a permanent practice — PHPStan/Psalm, Rector, or a more actively maintained composer-unused implementation cover adjacent ground with ongoing support.
- You actually want the inverse problem solved: packages used but not declared (that's a different class of tool, e.g. require-checker style analysis).
- Your team cannot absorb a manual review step — the output is a candidate list, not a safe auto-delete list.
How to Pitch It (Stakeholders)
To executives / sponsors: "We have dependencies in production that our code never uses. They still cost us money — in container size, CI minutes, license review, and vulnerability alerts we have to triage. This is a free, MIT-licensed scanner that produces a concrete list of what we can remove. It's a low-risk, one-time audit that shrinks our attack surface and our maintenance burden, and it takes days, not quarters. One caveat: the tool hasn't been updated since 2022, so we treat its output as a candidate list our engineers verify — not an automated change."
To engineering leadership: "It's a static scan over composer.json and our source tree to flag declared dependencies with no detectable usage. We run it as a one-off audit or an advisory CI job, not a blocking gate — it will produce false positives on dynamic resolution and Laravel auto-discovery, so every removal gets a human sign-off and a green test suite. It complements PHPStan/Rector rather than replacing them. Consider it the cheap first 80% of a dependency-cleanup initiative; if the workflow proves valuable, we migrate to a maintained alternative."
Positioning in one line: a low-cost, low-commitment diagnostic that converts "our dependency list feels bloated" into a prioritized, verifiable cleanup backlog — adopt as an audit, not as infrastructure.