Composer Dependency List Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for a compliance surface, not a core feature. This package's only real job is reading Composer's installed-package metadata (composer.lock / vendor/composer/installed.json) and handing back name, version, description, license, and homepage per dependency. That is a 1–2 day internal build. The decision this supports is "do we buy a dependency to render an attribution page, or write 80 lines of JSON parsing?"
• Roadmap slot for "Open Source Licenses / Third-Party Credits" screens. If legal, procurement, or an enterprise customer has asked for an in-product attribution page or a package inventory export, this is a candidate implementation — typically an /about/licenses page, an admin-only dependency report, or a CSV attachment to a security questionnaire.
• Dependency inventory for audits and security questionnaires. Same underlying data feeds SOC 2 / vendor-diligence requests ("list your third-party components and licenses"). Useful for deciding whether inventory is a manual quarterly task or an automated one.
• Scope clarification that changes the decision: despite being framed as a Laravel/PHP package, this is a Symfony bundle (frostieDE/...-bundle, registered via the Symfony kernel). In a Laravel codebase it is not drop-in; you would be pulling in a bundle you cannot boot, or cherry-picking its classes. That alone usually flips the decision to build.
• Adoption risk register entry. 0 stars, 0 dependents, no community, effectively a single-maintainer hobby repo. Runtime risk is genuinely low (read-only, no network calls, MIT), but the maintenance risk is high — no upstream fixes, no security response, no PHP-version roadmap.

When to Consider This Package

Consider it when all of these hold:

• The application is Symfony, not Laravel, and already registers bundles — otherwise the integration cost exceeds the build cost.
• The need is narrow and internal: a credits/licenses page, an admin dependency listing, a one-off inventory export.
• You accept an unmaintained dependency because the code path is read-only and failure is cosmetic, not transactional.
• You want a reference implementation to read before writing your own — arguably its highest-value use at this maturity level.

Look elsewhere (or build) when:

• You are on Laravel — parse composer.lock directly or use a maintained Composer-adjacent library.
• You need a real SBOM (CycloneDX/SPDX) rather than a human-readable list — use the CycloneDX PHP Composer tooling.
• You need vulnerability data — that is composer audit or a security-checker, a different product.
• You need license policy enforcement in CI (block GPL in a distributed binary) — use a license-checker in the pipeline, not a display-layer bundle.
• You need SLAs, a security contact, or a package with a release cadence. Zero dependents means zero field-testing; you will be the first integrator.

How to Pitch It (Stakeholders)

To executives: There is a small, MIT-licensed PHP component that lists every third-party library we ship, with version and license — the raw material for an attribution page and for answering customer security questionnaires. Cost is near zero, but so is adoption: no stars, no downstream users, one maintainer. Recommendation is not to adopt it as a dependency. Recommendation is a timeboxed spike (≤2 days) to read it as a reference and build the equivalent internally against composer.lock. That gives us the compliance capability, removes a single-maintainer supply-chain item from our tree, and keeps the output under our own control.

To engineering: It is a thin Symfony bundle wrapping Composer's installed.json. Integration in Laravel is non-trivial, the surface is small enough to reimplement, and we get to own the data shape (which we will need to change for SBOM export and CI license checks anyway). Use it as a spec, not a dependency. If we do adopt, pin the version, isolate the call behind an interface, and treat parsing failures as non-fatal.