Laravel Wave Laravel Package

Product Decisions This Supports

• Build vs. buy (initial evaluation). This is the first structured assessment of jeffgreco13/laravel-wave, triggered by the v2.0.0 major release. The decision to be made is whether to add it to our dependency graph at all, and if so whether to adopt the 2.x line or pin to the mature 1.x line (v1.2.0) while it stabilizes.
• Upgrade-window and version-pinning policy. A jump from 1.2.0 to 2.0.0 is a semver-major event. That means breaking changes exist by definition, even though the published release notes only link to a compare/v1.2.0...v2.0.0 changelog with no inline summary. This drives a concrete decision: what Composer constraint we allow (^1.2 vs ^2.0) and who owns the migration.
• Roadmap sequencing. Major releases signal an actively evolving public API. If we commit to the 2.x line, we should budget one migration cycle per major release in our maintenance capacity — an ongoing cost, not a one-time integration cost.
• Vendor / maintainer-risk decision. This is a single-maintainer community package. Adopting it is a bet on that individual's continued attention. If the capability maps to a committed roadmap item, that bet may be worth taking; if it maps to a "nice to have," it is not.
• Scope decision for the current cycle. The release notes are insufficient to characterize the new surface area. The immediate product action is to route the changelog diff to engineering for a 30-minute read before this package appears in any sprint scope — do not let it into a release train on the strength of a version number alone.

When to Consider This Package

Consider adoption when:

• The capability it provides is on the committed roadmap and would otherwise require us to write and maintain equivalent glue code ourselves.
• An engineer has read the full v1.2.0...v2.0.0 compare diff and can state, in plain language, what breaks and what is new. Treat the absence of an inline changelog as a checklist item, not a red flag on its own.
• Our Laravel and PHP version floors are confirmed compatible with v2's composer.json constraints — major releases routinely drop support for older framework versions.
• We are comfortable with bus-factor-1 risk, or we have a documented fallback (fork plan, or the integration surface is small enough to replace).
• We can adopt 2.x greenfield rather than migrating existing production usage mid-cycle.

Look elsewhere (or defer) when:

• We need an SLA, a supported LTS window, or a security-response commitment. Single-maintainer packages do not provide these.
• The net-new code we'd avoid is small — under a few hundred lines of straightforward glue. Owning it is often cheaper than owning a migration.
• The package has any part in the auth, payments, or data-integrity path and cannot be covered by our own integration tests.
• We would be adopting it for speculative future use rather than a current, scoped requirement.

Do not upgrade an existing 1.x installation until the compare diff has been reviewed and a rollback path is defined.

How to Pitch It (Stakeholders)

For executives: We are evaluating a small, free, community-maintained Laravel library. It would let us delete some custom code we'd otherwise own. The cost is low; the risk is that it is maintained by one person and just shipped a breaking major version. Recommendation: approve a short technical review before committing, not a blanket adoption.

For engineering: Version 2.0.0 is a semver-major release off 1.2.0, and the release notes contain only a changelog link — no breaking-change summary, no migration guide, no deprecation list. Before we touch it: (1) read the compare/v1.2.0...v2.0.0 diff, (2) check the composer.json framework and PHP constraints for dropped support, (3) confirm the package's own test suite and CI are green on 2.x, (4) state the rollback plan and whether our composer constraint stays on ^1.2 for now. Come back with a one-paragraph "what breaks and what's new" summary so we can make the adopt/pin/defer call on evidence rather than on the version number.