Cookie Consent Bundle Laravel Package

Product Decisions This Supports

• Compliance surface area triage: Cookie consent is a legal requirement (GDPR/ePrivacy, AVG in NL) that applies to essentially every consumer-facing product with EU traffic. This package is a candidate input to the "do we build, buy, or adopt OSS" decision for that requirement — but it is only one data point, not a recommendation.
• Buy-vs-build framing for a commodity capability: Consent banners are undifferentiated table stakes. A PM's instinct should be to minimize engineering spend here and redirect it to core product. An MIT-licensed bundle is attractive on paper for that reason; the low adoption signals (0 stars, 0 dependents, score 0.2) mean the real cost is likely integration and ongoing stewardship, not licensing.
• Framework-fit gate (critical): This is a Symfony bundle, not a Laravel package. It registers via Symfony's bundle/kernel and DI container conventions. If your stack is Laravel, this is effectively not adoptable without a rewrite — that decision alone likely closes the evaluation. It only becomes relevant if you run Symfony (or a mixed PHP estate).
• Roadmap input for consent scope: Use the package's feature set as a checklist of what "minimum viable consent" means for your product — cookie categorization, opt-in before non-essential cookies fire, consent persistence, withdrawal of consent, and audit trail. Note what it likely does not cover: consent log retention, granular per-vendor purposes (TCF), server-side enforcement, and re-consent on policy change. Those gaps are where your roadmap and legal review actually live.
• Risk-register entry: A single-maintainer, zero-adoption dependency handling a legally load-bearing function is a supply-chain and continuity risk. That's a decision to document, not just an engineering detail.

When to Consider This Package

Consider it only when all of the following hold:

• Your application is Symfony-based (or you're willing to vendor/port the logic). For a Laravel codebase, look elsewhere — see below.
• You need a basic, self-hosted, first-party consent banner with no third-party SaaS dependency, no data leaving your infrastructure, and no per-pageview vendor fees.
• Your legal scope is simple: a handful of first-party cookie categories, EU/UK traffic, no IAB TCF obligations, no ad-tech vendor chain requiring standardized consent strings.
• You have engineering capacity to own the code — fork it, review it, patch it, and pin the version. With 0 stars and 0 dependents, there is no community to absorb that work.

Look elsewhere (or build in-house) when:

• Stack mismatch: Laravel, or any non-Symfony PHP framework. Don't force it.
• You need a maintained, audited dependency. Last release August 2024 and no visible adoption means thin maintenance signal — acceptable for a 200-line banner, not for a compliance control you'll be asked to evidence in an audit.
• You need consent logging/evidence: regulators and enterprise buyers increasingly ask you to prove consent. A banner that only sets a cookie is not enough; you need server-side consent records with timestamps and versioned policy text.
• You need Google Consent Mode v2, TCF, or tag-manager integration — commercial CMPs (Cookiebot, Osano, Usercentrics, Klaro as a lighter OSS option) cover this and this package does not.
• You have no legal review capacity: no package substitutes for counsel deciding what categories you actually need.

How to Pitch It (Stakeholders)

To executives: Cookie consent is a mandatory cost of operating in the EU, not a differentiator. We evaluated a free, MIT-licensed option. Our recommendation is to not adopt it as-is: it's built for Symfony rather than our stack, has no meaningful user base or maintainer depth, and covers the banner but not the audit trail our enterprise customers and regulators will ask for. The cheapest credible path is either a thin in-house implementation scoped to our actual cookie usage, or a modest commercial CMP spend — either way, this is a small, bounded line item, not a platform decision.

To engineering: This is a Symfony bundle; treat it as reference material, not a dependency, unless we're on Symfony. Read it for the consent-state model and cookie-gating approach, then implement the equivalent in our framework with tests around: default-deny for non-essential cookies, persistence, and withdrawal. If we do adopt it, we fork and pin — nobody else is watching this repo.

Bottom line for the decision log: Real problem, weak candidate. Adopt only on Symfony with simple legal scope and a named internal owner; otherwise build a minimal in-house banner or buy a CMP.