Laravel Nova Stubs Laravel Package

Product Decisions This Supports

• Runtime modernization / upgrade planning: 2.1.0 adds PHP 8 support, which is the gating signal for whether this package can stay in the stack as we move to Laravel 9+ and PHP 8.x runtimes. This directly informs the "upgrade vs. replace" decision for any Laravel workstream currently pinned to PHP 7.x.
• Build vs. buy: PHP 8 support on a 2.x line is evidence of active maintenance. That shifts the default toward buy/adopt for the functionality it covers, rather than writing and owning an in-house equivalent that we would have to keep patched across PHP upgrades ourselves.
• Roadmap sequencing: because PHP 8 compatibility is table stakes for the rest of our Laravel modernization, this release can unblock or de-risk dependent roadmap items — it should be sequenced ahead of any framework upgrade epic rather than treated as an unrelated dependency bump.
• Risk/technical-debt register: remaining on an older major of this package now carries a visible cost (staying on an unsupported PHP runtime). That is a concrete debt item with a named remediation path.
• Use cases: internal Laravel services and tooling that need to run on PHP 8; anything where we were previously blocked from adopting this package purely on runtime compatibility.

Caveat: this assessment is based solely on the 2.1.0 release note. The package's functional scope, license, and maintenance cadence still need verification before it is treated as evaluated.

When to Consider This Package

• Adopt when: you are on (or migrating to) PHP 8 / modern Laravel, the package's functional scope matches a need you would otherwise build in-house, and you can confirm the 2.x line is the actively maintained one (recent releases, responsive issue tracker).
• Adopt as a migration enabler: if PHP 8 compatibility was the single blocker keeping you off a newer framework version, this release removes that blocker and adoption is low-risk relative to the alternative.
• Look elsewhere when: you are staying on PHP 7.x (the value of this release is nil for you), the package is a thin wrapper you could own in a few dozen lines, or you cannot confirm ongoing maintenance — a single release note is not a maintenance track record.
• Due diligence before committing: confirm PHP 8 compatibility is tested rather than merely declared (CI matrix, PHPUnit run on 8.x), check whether 2.x introduces breaking changes from whatever version you would be upgrading from, and review the changelog for 2.0 to understand the upgrade path.

How to Pitch It (Stakeholders)

For executives: the package we are evaluating now supports PHP 8, the runtime our platform is standardizing on. That removes the main compatibility objection and lets us include it in the modernization plan instead of paying to build and maintain the same capability ourselves. The cost of this release is effectively zero; the cost of not taking it is staying on an end-of-life PHP version.

For engineering: 2.1.0 adds PHP 8 support, so the package can live in the same runtime target as the rest of our Laravel services — no polyfills, no separate PHP 7 sidecar. Before we commit, verify the PHP 8 support is backed by CI (not just a version constraint bump), review the 2.0 → 2.1 upgrade notes for breaking changes, and confirm the maintainers are actively releasing. If those check out, adopt; if not, treat it as a candidate rather than a dependency.