Cookie Notice Laravel Package

Product Decisions This Supports

• Compliance-readiness for EU/UK traffic. Adding a cookie banner is a gating item for launching or marketing into GDPR/ePrivacy jurisdictions. This package makes that a config-and-Blade task rather than a front-end project, so it directly unblocks a market-expansion or privacy-review milestone on the roadmap.
• Build vs. buy on consent UI. The alternative is a commercial CMP (Cookiebot, OneTrust, Osano) at recurring cost plus a third-party script in the critical path. For a single Laravel-rendered site with a small cookie inventory, self-hosting a ~one-file banner is cheaper and avoids vendor lock-in and an extra external dependency in the page head.
• Reduce third-party script surface. Marketing/legal increasingly ask "what runs before consent?" A first-party, self-hosted banner keeps the consent interaction inside the app, which is easier to justify in a security questionnaire than an injected vendor tag.
• Feature-level use cases: a site-wide notice with accept/decline that persists in a cookie or session; localized copy per locale; a banner that stays out of the way once a choice is recorded (the v10.2.2 fix directly serves this last case — see below).
• Scope boundary to state explicitly in the PRD: this is a notice/acknowledgement banner, not a full Consent Management Platform. It does not provide per-vendor consent state, consent receipts or audit logs, geo-targeted display, Google Consent Mode v2 signaling, or IAB TCF strings. If the roadmap includes any of those (likely once you run paid media in the EU), plan for a CMP or a custom build — this package buys you months, not years.

On v10.2.2 specifically: low-risk patch. It fixes the banner flashing on page load for visitors who had already recorded a preference — a visible trust/UX defect that also invites "why am I being asked again?" support tickets and complaints from privacy-conscious users. The remaining change is a Dependabot CI bump with no runtime impact. No breaking changes, no deprecations, no migration work. Worth taking on the next routine dependency pass, not worth an out-of-band release, and worth mentioning in release notes to stakeholders only as "banner no longer re-appears for returning visitors."

When to Consider This Package

Adopt when:

• The app is Laravel (v10/v11-era), server-rendered with Blade, and the cookie inventory is short and stable (analytics, session, a preference cookie or two).
• You need a notice banner shipped this sprint and can accept a config-file-driven design: publish config and views, set copy/position/styling, done.
• You want the banner in version control, reviewable in a PR, and free of an external script or subscription.
• Legal has signed off on an "acknowledge and continue" model rather than a hard block-on-decline model.

Look elsewhere when:

• You need defensible consent records (timestamped, per-purpose, exportable) — that is CMP territory and this package will not satisfy a regulator or an enterprise customer's DPO.
• Consent must gate scripts conditionally (Consent Mode v2, GTM triggers, per-vendor toggles). Expect to write that glue yourself; budget for it rather than assume it ships.
• The front end is a SPA, Next.js, or mobile app — the banner lives in Blade, so it does not travel.
• You need geo-based display (EU-only banner), A/B testing of consent copy, or multi-domain/multi-brand central management.
• You have a strict CSP with nonces — verify the inline-script/asset publishing story before committing, and confirm maintenance cadence: this is a single-maintainer package, so weigh bus-factor against how much of your compliance posture you want to hang on it.

Mitigation if you adopt: keep the copy and cookie list in config under your own review, and treat the package as replaceable — the integration surface is one Blade include plus middleware, so swapping to a CMP later is a contained change.

How to Pitch It (Stakeholders)

For executives: We can close our cookie-consent gap this sprint with an open-source Laravel component instead of a paid consent platform, deferring a recurring vendor cost and a third-party script on every page. It is the right size for where we are: a single Laravel site with a short cookie list. Be clear about the ceiling — it gives us a compliant notice, not the auditable consent records a large enterprise buyer or a regulator may later ask for. If EU paid media or enterprise sales enter the plan, we should revisit with a real CMP; that decision is a quarter away, not a blocker now. Latest patch (v10.2.2) fixes the banner re-appearing for visitors who already accepted — a small but visible polish item with no migration cost.

For engineering: composer require plus publishing config/views/assets; the banner is a Blade include and preference persistence is handled for you. v10.2.2 is a safe patch — one front-end fix and a CI dependency bump, no breaking changes or deprecations, so it can ride along with the next dependency update. Two caveats to size in the ticket: it is not a consent-gating mechanism (any script-conditional logic, Consent Mode, or per-vendor state is our code), and it is a single-maintainer dependency — keep our customization in config and our own views so a future swap stays cheap.