Cookie Consent Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for consent management. This is the "buy-free" lane: an MIT-licensed, self-hosted consent modal covering the baseline scope — category toggles (necessary / analytics / marketing / preferences), a blocking modal on first visit, and optional persistence of consent records. It answers "do we need to build a CMP from scratch?" with a credible not yet.
• EU/GDPR market-entry gating. Any roadmap item that drops non-essential cookies or pixels (product analytics, ad attribution, personalization, A/B testing, embedded video) is blocked on a consent mechanism. This package unblocks that dependency cheaply, letting the feature ship this quarter instead of after a compliance epic.
• Evidence-of-consent capability. The optional consent logging turns "we show a banner" into "we can produce a timestamped record of what a user accepted, when, and for which categories" — the artifact legal and security teams actually ask for during a DPA review or a subject access request. Treat this as the highest-value differentiator at this maturity level.
• Stack fit decision (the real one). Despite the framing, this is a Symfony bundle, not a Laravel package. That single fact drives the decision: adopt directly if the target app is Symfony; budget a port (service provider, publishable config, migration, Blade component, consent model) if the target is Laravel. This is a 1–2 day job in Symfony and closer to 1–2 weeks plus permanent internal ownership in Laravel.
• Vendor consolidation. Replaces a third-party CMP script with code we host. Relevant where CSP, page-weight budgets, or a "no third-party JS on checkout/auth pages" policy is in force.
• Upstream trajectory check (new in v1.19.0). The services, controllers, form types, Twig extension, and DI classes we would otherwise subclass are now marked @final, with real final promised in 2.0. That is a healthy maintainer signal but also a fork-hazard notice: any Laravel port or Symfony customization should compose, not extend, so the eventual 2.0 bump is a version bump rather than a rewrite. It also confirms the project is being actively hardened, which strengthens the "vendored dependency with a plausible upgrade path" story versus an abandoned one.
• Roadmap honesty. This supports an MVP/launch decision, not a strategic bet. It does not cover IAB TCF, geo-based banner variants, tag-manager-driven vendor blocking, consent expiry/re-prompt policy, multi-domain/multi-brand consent scoping, or accessibility certification. If any of those are on the 12-month roadmap, this is a bridge, not a destination.

When to Consider This Package

Consider it when:

• The application is Symfony/PHP and you need a working consent baseline within days, not a procurement cycle.
• You are pre-revenue, low-traffic, single-domain, EU-facing, and the compliance bar is "reasonable, documented effort" rather than enterprise-procured CMP.
• You want consent data to stay in your own database — no third-party processor, no additional DPA, no data-residency question.
• You accept fork-and-own: 0 stars, 0 dependents, and a single maintainer mean you should plan to vendor the code, review it, and carry it internally rather than treat it as an externally supported dependency. v1.19.0 improves the odds the code is worth carrying (see below) but does not change the ownership model.
• You need something small enough to audit. A bundle this size is reviewable in an afternoon by one engineer — a genuine advantage over a 200KB commercial CMP.
• You plan to upgrade to 2.0 and can live with composition instead of inheritance. The @final markings are the maintainer telling you the extension surface is closing.

Look elsewhere when:

• The stack is Laravel-only. The port is real work, and every future upstream change becomes a manual merge — a cost that rises, not falls, as upstream hardens toward 2.0.
• You need IAB TCF, Google Consent Mode v2, or tag-manager vendor blocking — these are table stakes for ad-funded or publisher models and are out of scope here.
• You need a contractual SLA, indemnity, security questionnaire, or named support contact. A zero-star MIT project offers none of these.
• Legal requires a pre-vetted vendor or a reviewed DPIA referencing a named processor. Using this shifts the entire compliance burden onto your team.
• You operate multiple brands/domains/regions with different consent rules, or need consent renewal on a policy cycle. (Translation key parity is now gated against en, which helps with localization hygiene, but there is still no geo-variant or re-prompt policy engine.)
• Accessibility is a hard requirement (WCAG 2.2 AA, EAA). No evidence of an audit; budget your own.

Pre-adoption verification (revised): the earlier red flag — no visible evidence that the consent-logging path was tested — is now substantially addressed. v1.19.0 adds a coverage gate that fails the build under 99% line coverage and publishes the measured PHP and TypeScript coverage in the README, plus a translation key-parity gate (en as reference) and an AI security audit item in the release checklist. That is more quality infrastructure than most zero-star packages ever get, and it materially de-risks the audit. Residual items to confirm before pinning a version: (a) that the consent-logging service specifically — not just the config/form types — is inside the covered set; (b) that the coverage number in the README corresponds to a tagged release, not to main; (c) the actual changelog and open-issue count, since the listed last-release date remains inconsistent with a project of this age and adoption. Also record the @final list in your vendoring notes so the 2.0 upgrade diff is scoped in advance.

How to Pitch It (Stakeholders)

To executives: We have a legal-blocking dependency on our EU roadmap — we cannot ship analytics, marketing pixels, or personalization features into the EU without a cookie consent mechanism. A commercial CMP runs roughly five figures annually plus a vendor security review. This package is MIT-licensed and self-hosted, so it costs us a few engineering days instead of a budget line and a procurement cycle, and no user data leaves our infrastructure. The latest release also shows a maintainer investing in the unglamorous parts — enforced test coverage, translation gates, a security checklist — which lowers the "is this abandoned?" risk that normally kills small-package adoption. The trade-off is explicit: it gets us to a defensible MVP baseline, not to enterprise-grade consent management. I recommend we adopt it as a bridge, scope the replacement trigger now (first enterprise customer, first ad-funded surface, or first regulator/DPA question we can't answer), and be clear internally that a package is not a compliance program — legal review of the banner copy, categories, and retention policy is still required.

To engineering: Small Symfony bundle, MIT, tiny surface area — a configurable modal with category toggles and optional consent persistence. One engineer can audit it in an afternoon. Two paths: (a) Symfony app — drop-in, 1–2 days to integrate, configure categories, and verify logging; (b) Laravel app — we port it: service provider, publishable config, migration for the consent table, Blade component, and a test suite covering the blocking behavior. Budget 1–2 weeks. Two things changed in v1.19.0 that affect how we build it: services, controllers, form types, Twig extension, and DI classes are now @final (real final in 2.0), so compose, don't extend — this applies to the Symfony integration and especially to the Laravel port, where subclassing upstream internals would be the obvious shortcut and the wrong one. Second, the release adds a ≥99% line-coverage gate, translation key-parity checking, and a security audit step. That is good news for review, but it is coverage of their suite, not of our port — we still write our own tests. Either way, we vendor the code and own it — 0 stars and one maintainer means no upstream guarantee. Assign an owner, pin a commit, record the @final surface, and add a smoke test that asserts non-essential scripts don't load before consent.

To legal/security: Consent state and (optionally) an immutable log of user choices are stored in our own database — no third-party processor, no additional DPA, no cross-border transfer question. The log gives us timestamped evidence of what was consented to and when, which is the artifact that matters in a subject access request or DPA inquiry. What it does not provide: vendor-level blocking guarantees, TCF interoperability, consent expiry policy, or an accessibility audit. Those remain ours to validate. On supply chain: the project is single-maintainer and unreviewed by any third party, but the current release shows enforced coverage thresholds, translation-key parity, and a release security checklist including an AI security audit — treat that as due-diligence input, not as an assurance we can cite.