Package Versions Laravel Package

Product Decisions This Supports

• Support & triage instrumentation ("what are they running?"). A dependency-version read that costs no runtime file I/O is exactly what you want behind a /health, /about, or admin-only diagnostics endpoint. When a customer files a bug, the first question is "which version of the library that owns this behavior are they on?" — this answers it deterministically from composer.lock instead of file scraping or guesswork.
• Build-vs-buy. The scope is deliberately tiny (composer plugin that code-generates a Versions class at install/update time; runtime lookups are static array reads). Buying costs one dependency; building costs a plugin, a lock-file parser, and a codegen step you must maintain through every Composer major. Build only if you need behavior it doesn't offer.
• Compatibility gating in your own products. If you ship a Laravel package, plugin, or module that must refuse to boot against unsupported versions of a dependency, getMajorVersion() is a cheap precondition check. This is a "fast fail with a clear message" feature, not a licensing or metering mechanism.
• Cache-key and asset-version derivation. Folding a short dependency version into cache keys or asset query strings gives you automatic invalidation on deploy without a separate build-stamp mechanism.
• Roadmap signal, not roadmap content. The existence of this package is itself a decision input: it says "we still run PHP 5.6 somewhere." Adopting it is a conscious acknowledgment of a legacy surface and should be paired with an explicit date for leaving that surface.
• Use cases it does not unlock: runtime dependency auditing, SBOM generation, CVE scanning, or license compliance. It reports versions of packages you already installed; it is not a supply-chain control.

When to Consider This Package

Consider it only when all of the following hold:

• You are on PHP 5.6 (or a stack pinned to Laravel 5.x-era dependencies) and cannot move — the upstream package requires PHP 7+.
• You need version lookups in hot paths where filesystem or composer.lock reads are unacceptable, or you need versions available in environments where the lock file isn't shipped.
• Your Composer version is pinned to 1.x, or you have verified the plugin works under your Composer 2 allow-plugins configuration — this is a Composer plugin, so install-time behavior depends on Composer's plugin API, and it predates Composer 2's plugin restrictions.
• You accept the lock-in cost: generated class is a build artifact, so CI must run composer install (not ship a stale generated file), and container image caching must not skip plugin execution.

Look elsewhere — decisively — when:

• You are on PHP 7.1+. Use Composer 2's built-in Composer\InstalledVersions (runtime API, maintained, no plugin, no generated file). This is the correct answer for essentially every new project and should be the default recommendation.
• You need maintenance, security response, or ecosystem validation. The last release is July 2016, it has 3 stars and 0 dependents, and the upstream project it backports is itself abandoned. There is no active maintainer, no compatibility work for modern Composer/PHP, and no community to catch regressions. This is a "vendor it, don't depend on it" candidate.
• You need semver satisfaction checks (does installed 2.3.1 satisfy ^2.0?) rather than raw version strings — this gives you strings and a major number only.
• Your threat model includes plugin supply-chain risk. A Composer plugin executes code at install time; a 10-year-unmaintained plugin in the install path is a real, if small, exposure. Fork it, pin it by commit, and review the code — it's a few hundred lines, so this is cheap.
• You need monorepo or path-repository support; behavior with non-lockfile-sourced packages is untested territory here.

Recommended posture: treat as a frozen, vendored utility for legacy applications only. Do not introduce it into any codebase with a PHP upgrade path, and add "remove this dependency" to the same epic that tracks the PHP 8 migration.

How to Pitch It (Stakeholders)

To executives: This is a ~zero-cost utility that lets our applications report exactly which dependency versions they're running, so support can diagnose customer issues without a call. It is not a strategic bet and not a security or compliance control. The only reason it appears on our radar is that it's the last package that still works on PHP 5.6 — so adopting it is a marker of legacy debt, not a modernization. Approve it as a bridge; fund the PHP upgrade as the actual decision.

To engineering: samsonasik/package-versions is a PHP 5.6 backport of ocramius/package-versions. A Composer plugin parses composer.lock at install time and code-generates a static version map, so Versions::getVersion('vendor/pkg') and getMajorVersion() resolve with no runtime I/O. Use it for /health output, support diagnostics, and cache-key derivation. Three caveats we own: (1) last release 2016, no maintained upstream — we vendor or pin it and read the source; (2) it's a Composer plugin, so it interacts with Composer 2 plugin allowlists and must run in every composer install (don't commit the generated class as source of truth); (3) for any codebase on PHP 7.1+, the answer is Composer\InstalledVersions from Composer 2 — no plugin, no generated file, maintained. Ship it only where PHP 5.6 is genuinely unavoidable, and file the removal ticket the same day.