Cookie Consent Bundle Laravel Package

Product Decisions This Supports

• Scoping the minimum viable consent experience. This bundle is a thin config wrapper around a front-end Cookie Consent banner (copy, position, theme, policy URL, accept/deny hooks). Treat it as a spec for what a first-release banner looks like — not a solution. It bounds the conversation; it does not close it.
• Build vs. buy vs. borrow. The package sits squarely in the "borrow — then discard" bucket: MIT, zero cost, zero dependents, archived. The real decision it informs is "fork/salvage this, hand-roll a Blade partial, or buy a real CMP?" — and its state argues for the hand-rolled partial over any fork.
• Roadmap placement of consent work. It cleanly separates a v1 UI task (a banner, hours-to-days of work) from a v2 platform concern (proof-of-consent records, granular per-category opt-in, script/tag gating before pixels fire, geo-based behavior, revocation, audit export). The package only addresses the first. Budget the second as a line item, not an afterthought.
• Feature framing for marketing and analytics stakeholders. It provides a concrete artifact to point at when Sales asks "are we GDPR-compliant?" — and the honest answer is: this gets us the notice, not the record. That framing prevents an accidental "consent is done" milestone.
• Use cases where this is genuinely sufficient: internal tools, short-lived campaign microsites, brochure sites with no ad pixels, and orgs in a single low-risk jurisdiction whose legal ask is literally "show a notice and link the policy."
• A decision this should force, not support: Google Consent Mode v2 and ad-pixel gating. Nothing here addresses it, and EU ad spend is usually what makes compliance commercially real. Surfacing that early prevents a false completion signal.
• A stack-fit decision it should also force: the brief calls this a Laravel/PHP package; it is a Symfony Bundle. In a Laravel codebase the PHP layer is dead weight and the only portable artifact is the JS/CSS plus the default config — so the PM decision collapses to "reference source, not dependency." Close the adoption ticket and keep the artifact as a design input.

When to Consider This Package

Consider it — as a reference, not a dependency — when:

• The stack is genuinely Symfony. For Laravel, the closest maintained equivalents to evaluate are whitecube/laravel-cookie-consent or spatie/laravel-cookie-consent, or a Blade partial plus the upstream JS plugin.
• You only need the front-end banner: configurable copy, accept/deny, policy link, a JS callback on acceptance.
• You are willing to treat it as vendored/forked code you own, not a maintained dependency. Archived, 15 stars, 0 dependents means no security patches, no Symfony 6/7 support, nobody to escalate to.
• The site is low-stakes and short-lived enough that "we'll swap it out later" is a defensible sentence.

Look elsewhere when:

• You need records of consent (GDPR Art. 7 accountability), user-level revocation, or an audit trail for a DPO or enterprise security questionnaire.
• You need tag gating — blocking GA4, Meta, LinkedIn, Hotjar before opt-in — or Google Consent Mode v2 for ad measurement.
• You need geo-targeting (EU banner, US opt-out model), IAB TCF, or multi-language consent copy at scale.
• You need SSR-consistent, CSP-friendly delivery, or any maintenance guarantee.
• Compliance is customer-facing: a SaaS selling into enterprise will be asked "which CMP do you use?" The answer needs a name — OneTrust, Cookiebot, Usercentrics, Osano, or open-source Klaro! — not an archived bundle.

Stack-mismatch bottom line: a PM reviewing this in a Laravel context should close the ticket and re-run the evaluation against a Laravel-native or vendor-agnostic option.

How to Pitch It (Stakeholders)

To executives: "This is a free, MIT-licensed banner wrapper. It costs nothing and it is archived — unmaintained, fifteen stars, zero known dependents. It gets us the notice in front of users. It does not get us the record of consent, ad-pixel blocking, or geo-targeting. My recommendation is not to adopt it: we spend half a sprint building the equivalent in-house using it as a template, and we budget separately for a commercial CMP if and when we start selling into EU enterprise or running paid EU media. Adopting it saves roughly two days and creates a maintenance orphan we'd own forever."

To engineering: "Don't add this dependency. It's a Symfony bundle and we're on Laravel; it's archived with no current-framework support. Read it as documentation: the surface area is a config block and a view partial. Copy the pattern — one Blade component, the upstream Cookie Consent JS, a config entry for policy URL and theme, and a callback that gates analytics initialization. One to two days. Then we own it, under our CI and review process."

To legal/compliance: "This delivers a consent banner. It does not deliver proof of consent, per-category granularity, or revocation. If your requirement is 'notice plus policy link,' we're covered in a sprint. If your requirement is 'demonstrable consent per data subject,' this package is out of scope and we need to discuss a CMP (Cookiebot, Osano, Usercentrics) or a maintained MIT alternative (Klaro!, vanilla-cookieconsent)."

Decision requested: approve the in-house banner build (small, v1) and defer the CMP buy/no-buy decision to the point where EU ad spend or enterprise procurement forces it. Sequence compliance requirements and script inventory first; the banner UI comes last.