Laravel Cookie Consent Laravel Package

Product Decisions This Supports

• Build vs. buy for consent UI: This package covers the "banner + preference persistence" slice of cookie compliance for Laravel/Livewire apps. Adopting it converts a recurring, low-differentiation build item into a dependency, freeing engineering for product work. For a Livewire-based stack, that is usually the right trade.
• Scope of the compliance surface: v1.1.0's new config file and asset-management services move this from a hardcoded banner toward a configurable component — positioning, copy, and behavior can now be tuned per product/brand without forking. That supports shipping consent UI across multiple apps or locales from one dependency.
• Roadmap sequencing: The release is primarily internal quality work (refactors, Laravel testing framework, exception handling, service extraction). Translate that as: the maintainer is investing in maintainability, not in compliance depth. Do not plan roadmap items that assume features like geo-detection, tag/script blocking, consent logging, or IAB TCF — those remain out of scope and would be our build (or a commercial CMP).
• Upgrade budgeting: The notes explicitly warn that users extending the package may need to update implementations, and some files were removed. If we have forked, published, or subclassed anything (views, commands, Livewire component paths), treat v1.1.0 as a migration task, not a patch bump. Budget a spike before committing to the upgrade in a release train.
• Dependency governance: Shipping breaking changes in a 1.0.0 → 1.1.0 minor release signals the project is not strictly semver-reliable at this stage. That's a policy decision: pin exact versions, review changelogs on every bump, and avoid floating constraints in composer.json.
• Use cases this fits: internal tools, admin panels, marketing/content sites, and MVPs already on Livewire where a straightforward accept/decline banner is sufficient and legal has approved the copy.
• Use cases this does not fit: consent as a regulated, auditable control (see below).

When to Consider This Package

Consider it when:

• The product is Laravel + Livewire and the banner should live in the existing Blade/Livewire layer rather than as a separate JS widget.
• A cookie banner is a checkbox requirement — accept/decline, persist choice, no per-vendor consent records.
• Engineering capacity is tight and a maintained, configurable component beats a bespoke build.
• We can tolerate a single-maintainer dependency for a compliance-adjacent but non-critical UI concern, and we're willing to pin versions and occasionally vendor/fork.
• We want the customization surface (config file, service layer) to adapt copy and behavior per brand without patching source.

Look elsewhere when:

• The requirement is a real CMP: script/tag blocking before consent, granular per-purpose or per-vendor consent, consent receipts/audit logs, geo-based behavior, IAB TCF, or DSAR integration. Use a commercial CMP (OneTrust, Cookiebot, Osano, Usercentrics) instead — this package will not get you there.
• The frontend is a SPA or non-Livewire stack (React/Vue/Next); the Livewire coupling becomes friction, and a framework-agnostic or hosted CMP is simpler.
• You need a vendor contract, SLA, security review, or indemnification — an OSS package with one maintainer won't satisfy procurement for a compliance-critical control.
• Legal requires demonstrable, versioned proof of consent capture; this package's persistence model is not an evidence store.
• The team has already extended or forked v1.0.0 heavily — the v1.1.0 refactor (command changes, Livewire component paths, removed files) makes the upgrade cost potentially exceed the value.
• Multi-domain or multi-tenant consent state needs central management.

How to Pitch It (Stakeholders)

For executives: Cookie consent is a legal-exposure item that appears on every roadmap and produces zero differentiation. This package lets us satisfy the standard banner requirement on our Laravel/Livewire products for essentially the cost of configuration instead of a build — days, not weeks — and keeps the compliance copy under our control. The v1.1.0 release is a maintenance release: the maintainer refactored internals, added a configuration layer so we can customize without forking, and improved error handling. Important caveat: it contains changes that can break teams that have customized the package, and it ships those changes in a minor version. Recommendation: adopt, pin to an exact version, and treat upgrades as reviewed changes rather than automatic. This covers the banner; it does not replace a commercial consent management platform if Legal later requires granular vendor consent, audit logs, or geo-targeting — that would be a separate buy decision.

For engineering: Drop-in Livewire component; v1.1.0 adds a config file, asset-management and configuration services, updated Livewire component paths, better exception handling, and migration of the test suite to Laravel's own testing framework. That last point cuts both ways: it signals active maintenance, but means the package's tests no longer run on the framework we might already have wired into CI, and published/removed files mean any local overrides, custom commands, or component references need auditing before upgrade. Concretely: pin the version, diff the published assets and config against our overrides, run the upgrade on a branch, and re-verify the banner renders and the consent cookie persists. If our customization is deep, evaluate vendoring the package so upstream refactors can't silently break us.