Package Versions Laravel Package

Product Decisions This Supports

• Feature: deployment/version visibility from inside the app. This package answers "which version of dependency X is actually running in this environment?" without touching the filesystem at request time. That unlocks: admin/ops health endpoints, a X-App-Version response header, version-stamped cache-busting for compiled assets, and enriching error reports (Sentry/Bugsnag/CloudWatch) with dependency versions so a stack trace is self-describing.
• Feature: cache-busting and asset fingerprinting keyed to real build state. If your asset pipeline needs a stable cache key derived from "what was installed at build time," a compile-time-baked version list is cheaper and more reliable than reading composer.lock per request.
• Build vs. buy (buy, with a caveat). The capability is trivially small — a helper that reads composer.lock and memoizes it is ~20 lines. The package wins on correctness (edge cases around composer install variants, classmap-authoritative mode, --no-scripts) and on the "zero I/O at call time" property, which removes it from the latency budget entirely. Caveat: Composer 2 ships its own runtime API (Composer\InstalledVersions, composer-runtime-api ^2.0) that overlaps with this package's core value. Before adopting, verify whether your Composer version already gives you this for free — if it does, the build-vs-buy decision may collapse to "buy nothing."
• Roadmap: not a roadmap item — it's plumbing. Treat it as a one-afternoon enabler for an observability/supportability epic you're already funding. It should never headline a release.
• Use cases ranked by business value: (1) support/incident triage — shortening "what's deployed in prod?" from a Slack thread to one API call; (2) multi-service/multi-tenant version-skew detection; (3) cache invalidation correctness; (4) license/SBOM-adjacent reporting from within the running app. The performance angle is real but marginal — it's a hygiene win, not a speed win.

When to Consider This Package

Adopt when:

• You run multiple environments/services and routinely lose time reconstructing "what version is actually deployed."
• You have a strict per-request I/O/latency budget and want version data to cost nothing at runtime.
• You want this to be framework-agnostic plumbing inside a Laravel app — no service provider, no config file, no bootstrapping. (That's also why it isn't really a "Laravel package"; expect no Laravel-specific ergonomics or support.)
• Your intake policy is comfortable with a single-maintainer dependency with a very small, stable surface.

Look elsewhere (or build in-house) when:

• You're on Composer 2 and Composer\InstalledVersions already covers your need — adding a dependency for equivalent functionality is pure surface-area cost.
• Your deploy pipeline runs composer install --no-scripts or --classmap-authoritative; per the changelog these are supported but with degraded performance, which undercuts the main selling point.
• You need versions of things not in composer.lock (globally installed tools, non-Composer artifacts) or dynamic per-request resolution.
• You need a vendor with an SLA beyond Tidelift, or your OSS intake process flags non-technical/political content in repository READMEs — this repo includes one, so route it through governance review rather than letting an engineer composer require it on a Friday.
• You need active feature development. Release notes are dominated by Renovate bot dependency bumps and PHP-version support (8.3/8.4/8.5). That's healthy maintenance, not momentum — assume no new capabilities are coming and don't architect around future features.

Risk flags to record: single primary maintainer (bus factor), and a dataset showing zero dependents — likely a graph artifact, but worth a quick sanity check against Packagist before anyone cites it as a red flag.

How to Pitch It (Stakeholders)

For executives: "A small, mature, MIT-licensed utility that lets the application report exactly which dependency versions are running in any environment, with no performance cost. It doesn't change the product; it shortens incident triage and removes guesswork from releases. Cost: one dependency, one afternoon, zero infrastructure change. Downside risk: it's maintained by one person, it's a candidate for replacement by Composer's own built-in API, and it's easy to remove if either becomes a problem — the integration surface is a handful of call sites behind our own wrapper."

For engineering: "Use it as the source of truth for a /health or /version endpoint, response headers, and error-context enrichment. Wrap it in a single internal AppVersion facade so we can swap the implementation to Composer\InstalledVersions (or read the lockfile ourselves) without touching callers — that wrapper is the actual decision; the package underneath is reversible. Enable optimize-autoloader as the README recommends, confirm your composer install flags, and don't spread direct Versions::getVersion() calls across the codebase."

Decision requested: approve as a low-risk supporting dependency behind an abstraction, with a scheduled re-evaluation if Composer's native API fully covers us.