Composer Dependency List Bundle Laravel Package

Technical Evaluation

Architecture fit Despite the shared PHP runtime, this is a Symfony bundle, not a Laravel package. It uses the frostieDE namespace and -bundle suffix convention, which implies a Bundle class, a DI Extension, compiler passes, and Symfony Console commands registered through the Symfony kernel. Laravel has no bundle registration mechanism, no kernel boot cycle to hook, and its service container is not the Symfony container (it only borrows individual Symfony components). Net: the package's packaging layer is unusable in a Laravel app as-is.

The domain logic — enumerating installed Composer packages and their versions/licenses — is framework-agnostic and small. That is the only part worth evaluating.

Integration feasibility Low-to-moderate. Two viable paths:

1. Adapt (1–2 dev days): vendor/fork the source, delete the bundle/extension/compiler-pass scaffolding, expose the reader as a plain class, bind it in a Laravel service provider, and re-signature any commands as Artisan commands. Realistically you keep ~20–50 lines of the original.
2. Reimplement (<1 day): Composer\InstalledVersions::getAllRawData() and vendor/composer/installed.json are shipped by Composer itself and are present in every Laravel install. Producing a dependency listing is a short, well-understood task with zero third-party surface.

Given the effort delta is roughly half a day in favour of reimplementing, adaptation only makes sense if the package contains non-obvious logic (license normalisation, dependency-tree traversal) verified during a source read.

Technical risk

• Adoption risk: high. 0 stars, 0 dependents, single maintainer. There is no community validation, no downstream bug surface, and no signal that anyone has run this in production. A TPM should treat this as effectively unmaintained until proven otherwise.
• Supply-chain risk: low-moderate. MIT and likely a thin dependency tree (Symfony components only), so blast radius is small — but a dead package still accrues audit and upgrade debt.
• Compatibility risk: moderate. Symfony-component version pins (plausibly ^4/^5) can collide with the Symfony 6/7 components Laravel 10/11 requires, producing composer update resolution failures. Verify the composer.json constraints before anything else.
• Information-disclosure risk: moderate. A dependency inventory exposes exact versions — a gift to an attacker scanning for known CVEs. If the package ships an HTTP controller rather than only a console command, it must never be reachable in production.

Key questions

1. Does it expose console commands only, or routes/controllers too?
2. Which Symfony and PHP version ranges does it constrain?
3. Does it read composer.lock at runtime (frequently absent from optimised production images) or vendor/composer/installed.json?
4. Is the source more than a thin wrapper over Composer\InstalledVersions?
5. Last commit date, open issues, and whether tagged releases exist?
6. Is the actual requirement an SBOM/dependency-audit artefact (a CI concern) rather than a runtime feature? If so, composer show --format=json and composer licenses --format=json already solve it with zero new dependencies.

Integration Approach

Stack fit Poor for Laravel, adequate for Symfony. On a Laravel codebase the bundle layer is dead weight; only the data-access logic transfers. The scored opportunity of 22.56 is consistent with this: thin functionality, wrong framework, no adoption — the upside of adopting is a few hours of saved typing.

Migration path If the source audit justifies reuse:

1. Fork to an internal namespace (MIT permits this) and pin to a commit SHA.
2. Strip the Bundle, DI Extension, and compiler passes.
3. Bind the remaining reader class as a singleton in a Laravel service provider; register the result as a deferred provider so it costs nothing unless resolved.
4. Reimplement any command as an Artisan command with an explicit --json flag for machine consumption.
5. Gate behind app()->environment('local') and an authorisation gate; never register a route.

If the audit shows it is a thin wrapper — the likely outcome — skip the fork and write the ~40 lines directly against Composer\InstalledVersions.

Compatibility

• Confirm PHP constraint against the team's floor (8.1/8.2/8.3).
• Check Symfony component constraints against the versions Laravel already pulls in; a pin below Symfony 6 will conflict and block upgrades.
• Confirm behaviour when composer.lock is absent and when vendor/ is installed with --no-dev.

Sequencing

1. Spike (0.5–1 day): read the source; answer the six questions above; produce a written build-vs-adapt recommendation.
2. Decide: default to build. Adaptation requires demonstrated non-trivial logic to justify itself.
3. Implement as an internal Artisan command, not a dependency.
4. Relocate the real need: if dependency inventory is for security/compliance, wire composer licenses --format=json and a composer audit step into CI and publish the artefact to the SBOM pipeline. That is where the requirement actually lives.

Operational Impact

Maintenance Adopting this transfers full maintenance ownership to the team at near-zero benefit. With 0 stars and no dependents there is no upstream to lean on, so every Laravel or PHP upgrade becomes an internal patch. An in-house implementation of equivalent scope is a similar maintenance burden but with no third-party audit surface and no fork-tracking overhead. Strongly prefer in-house.

Support No community, no issue-tracker signal, no documentation guarantees. MIT gives legal freedom to fork but no operational support. Escalation path is "the one maintainer" — i.e. none.

Scaling Negligible. Dependency enumeration is a CLI-time operation over a few hundred JSON records; sub-second at typical package counts. If it is ever wired into an HTTP path, cache the parsed result — parsing installed.json per request is wasteful and turns a compliance tool into a latency tax. The real scaling concern is organisational: an unmaintained package in composer.json accumulates upgrade friction across every environment, forever.

Failure modes

• Missing manifest in production: optimised images built with --no-dev and without composer.lock will fail at runtime. Most likely single point of failure.
• Composer resolution conflict on Symfony component pins, blocking unrelated framework upgrades — a delayed, high-cost failure.
• Container boot error if someone attempts to register the bundle in Laravel expecting it to work.
• Version disclosure if any HTTP surface is exposed, giving attackers a precise CVE target list.
• Silent abandonment: no security advisories will ever be filed against a package with zero dependents, so a vulnerability would go unannounced.

Ramp-up Technically trivial — any mid-level PHP developer understands the problem space in under an hour. The genuine cost is decision overhead: the team will spend more time evaluating, forking, and re-validating this package than it would spend writing the equivalent internal command from scratch.

Recommendation: Do not adopt. Run a one-day spike only to confirm the source is as thin as the metadata implies, then implement an internal Artisan command over Composer\InstalledVersions and push the dependency-inventory requirement into the CI/SBOM pipeline where it belongs. A zero-star, zero-dependent Symfony bundle is the wrong shape for a Laravel stack and the wrong bet for a TPM optimising maintenance cost.