Statamic Cookie Consent Laravel Package

Product Decisions This Supports

• Build vs. buy (the core decision). A Laravel/PHP package reaching v1.0-beta.4 with PHP 8 support is a candidate to replace in-house code. The decision this supports is whether to adopt a pre-1.0 dependency versus writing and maintaining the equivalent capability ourselves. At beta, the honest framing is "buy with a spike," not "buy and forget."
• Runtime upgrade roadmap. "Support PHP 8" is the release's only stated change, and it is the one that matters most to a PM: it unblocks, or at least stops blocking, a PHP 8 / modern-Laravel upgrade. Any package pinned to PHP 7.x is a line item on the platform-upgrade critical path; this release removes it from that list (subject to verification — see below).
• Adoption surface and blast radius. The PM decision is not "is this good?" in the abstract but "which of our services can take this dependency?" Beta-stage packages belong on internal tooling, admin surfaces, and non-revenue paths first — not on checkout, auth, or anything with a compliance boundary.
• Feature sequencing against a dependency's stability. Because the package is pre-1.0, any roadmap item that depends on its API inherits its churn risk. This assessment supports deferring those items until the dependency reaches GA, or scoping them so a breaking change costs a day rather than a sprint.
• Exit criteria and reversibility. A defensible adoption decision needs a defined "we back out if X" trigger. For a beta package, that means an abstraction seam at the integration point so the dependency can be swapped without a rewrite.

Caveat on the evidence. The only signal available is a single changelog line: Support PHP 8, on release v1.0-beta.4. There is no data on the package's scope, maintainer, download counts, test coverage, Laravel version matrix, or the beta-to-GA timeline. Every judgment below is therefore conditional and should be treated as a decision framework to be confirmed against the repo, composer.json constraints, and CI status before anyone commits engineering time.

When to Consider This Package

Adopt (conditionally) when:

• Your application is already on PHP 8.x and a supported Laravel major, so this release's headline change is actually consumable rather than aspirational.
• The capability it provides is adjacent to your core product — plumbing, admin, developer tooling, integrations — where a mid-cycle breaking change is an inconvenience, not an incident.
• You have verified, not assumed, the PHP 8 claim: check composer.json for the php constraint, confirm the CI matrix actually runs PHP 8.x, and confirm a clean install on your Laravel version. A changelog line is a claim; a green build is evidence.
• You can afford the pre-1.0 tax: pinned versions, a lockfile you don't casually bump, and a wrapping service class so the package's API doesn't leak across your codebase.
• The alternative is writing and owning equivalent code, and the maintenance burden of that ownership exceeds the cost of tracking someone else's beta.

Look elsewhere when:

• The capability is on a critical path — payments, auth, PII handling — where you need a stable, patched, ideally 1.x+ dependency with a security disclosure process.
• You are pinned to PHP 7.4 or an older Laravel major, in which case "Support PHP 8" is a migration prerequisite you don't yet meet, not an adoption trigger.
• The beta has been in beta for a long time with no GA signal, sparse commit activity, or a single unresponsive maintainer. Beta duration is a leading indicator of abandonment risk.
• You cannot inspect the source. For a package inserted into your request lifecycle, the ability to read and patch it is a hard requirement, not a nice-to-have.
• A mature alternative exists at 1.x or beyond. Choosing beta over stable needs a specific justification — usually a capability the stable option lacks — not just novelty.

How to Pitch It (Stakeholders)

For executives — one paragraph. There is a Laravel package at v1.0-beta.4 that just added PHP 8 support. That change matters less as a feature than as an unblocker: it takes the package off the critical path of our PHP 8 platform upgrade. The recommendation is a time-boxed, contained evaluation on a non-revenue surface, not a broad rollout. Because it is pre-1.0, we should assume its API will change before GA, so we plan for a cheap exit and pin the version. Cost of the evaluation is small and bounded; the downside of skipping it is either rebuilding equivalent code ourselves or discovering mid-upgrade that this dependency is the blocker.

For engineering — the operative points.

• This is a beta, and the release notes contain exactly one line. Do not read "Support PHP 8" as a compatibility guarantee for our stack until we've seen the CI matrix and run an install against our Laravel version.
• Integration should go through a thin adapter. No direct use of the package's API in domain code. This is what makes the beta-to-GA transition, or a replacement decision, a contained change.
• Pin the exact beta version in composer.json and treat upgrades as reviewed changes, not routine composer update fallout.
• Before we merge anything, we want three facts on record: the php constraint in composer.json, the actual CI matrix, and the maintainer's stated path and timeline to 1.0. If we can't get the third, that itself is the finding.

Decision being requested. Approve a fixed-effort spike (roughly one to two engineer-days) to validate PHP 8 compatibility against our stack and confirm the path to GA. Success → adopt behind an adapter on one non-critical service. Failure or ambiguous maintainer signal → stop, and revisit only if the package reaches 1.0 or a stable alternative disappears.