Composer Packages Laravel Package

Product Decisions This Supports

• Feature scoping for "instance info" surfaces. If your roadmap includes an admin diagnostics page, a "System Info / About" panel, or a customer-facing "what version are you running?" support widget, this package addresses the data-gathering half of that feature: it lets application code read installed package metadata (name, version, description, license) without shelling out to composer show or hand-parsing composer.lock.
• License and dependency compliance reporting. A recurring compliance ask (enterprise procurement, SOC 2 vendor inventories, open-source license audits) can be met by enumerating installed packages and their licenses. This package is one way to source that list.
• Build vs. buy — and the answer here is "build." The decisive PM input: Composer 2 ships Composer\InstalledVersions as a runtime API (getInstalledPackages(), getVersion(), getPrettyVersion()), which covers the majority of this package's value with zero third-party dependency. That reframes the decision from "adopt a package" to "write a ~30-line service class." Buying here only makes sense if you are pinned to Composer 1 or PHP 7.x-era tooling.
• Plugin/module discovery in a Laravel app. A plausible use case is introspecting the dependency graph to auto-register or display modules, or to gate features on the presence of a package. Worth validating whether Laravel's own service-provider/package-discovery machinery already solves it more idiomatically before allocating sprint time.
• SBOM and vulnerability scanning are not supported decisions. This package inventories packages; it does not produce CycloneDX/SPDX output or check advisories. For those requirements the correct build-vs-buy answer is composer audit plus dedicated SBOM tooling, not this.

When to Consider This Package

Adopt (or, more realistically, fork/vendor) only when all of the following hold:

• You need package metadata from inside application runtime code, not from CI or a CLI script.
• You are on Composer 1, or otherwise cannot use Composer\InstalledVersions.
• You accept ownership: last release was 2020-10-24, ~32 stars, and the repository is not confirmed reachable. Treat it as unmaintained sample code, not a supported dependency.
• You have reviewed the install-time risk. It is a Composer plugin, which executes with elevated privileges during composer install/update — a supply-chain review item that a plain library would not trigger.

Look elsewhere when:

• Composer 2 is available — use Composer\InstalledVersions and own the 30 lines yourself.
• You need a maintained dependency with a security-response path; a 2020 freeze fails most dependency policies outright.
• You need license compliance at scale — dedicated tooling (SPDX/CycloneDX generators, composer licenses) is more auditable than an in-app plugin.
• You need vulnerability data — use composer audit or a commercial SCA feed.
• You want a Laravel-native solution — reading composer.lock via a small injected service fits the framework's conventions better and keeps the dependency graph clean.

The MIT license is permissive and removes legal friction; it does not offset the maintenance and install-time-execution concerns.

How to Pitch It (Stakeholders)

To executives (one line): A small MIT-licensed utility that reports which packages are installed — useful for admin/support screens and license inventories, but it has been unmaintained since 2020, and the capability is now built into Composer itself. Recommendation: do not add it as a dependency; spend roughly one engineering day building the equivalent in-house and avoid the maintenance and supply-chain exposure.

To engineering: The only genuinely reusable idea here is "expose installed-package metadata to application code." On Composer 2 that is Composer\InstalledVersions::getInstalledPackages() plus getPrettyVersion() — no plugin, no install-time execution, no abandoned dependency. Implement it as a small injectable service (a Laravel singleton bound to an interface) with a cached result, and you get the same feature with a fraction of the risk. If you do evaluate the package, read the source first and pin it via a fork you control rather than pulling it transitively.