Cookie Bundle Laravel Package

Product Decisions This Supports

• Regulatory scope decision (Spain / EU): Whether the AEPD's 2024 cookie guidance — granular purpose categories, an accept/reject choice of equal prominence, and consent withdrawal that is as easy as giving it — is a compliance requirement for the next release, or a "someday" backlog item. The bundle's built-in banner, per-category configuration (technical/preferences/analytics/ads) and persistent "retract consent" floating button map almost one-to-one onto those obligations.
• Build vs. buy vs. adopt: A credible third option alongside "build our own banner" and "sign with a commercial CMP (Cookiebot, OneTrust, Didomi)." For a Symfony shop, this is a ~1–3 day integration instead of a multi-sprint build or an annual vendor contract — the decision is mainly speed to a defensible posture rather than feature depth.
• Framework strategy / tech-stack fit: This is a Symfony bundle, not a Laravel package. That is itself a decision: if the product surface is Laravel, adoption means either a port/fork (real engineering cost, plus owning a fork forever) or excluding it. Treat it as "Symfony-only" in any architecture review.
• Feature-level choices to sequence: Consent expiry/retention configuration, multilingual consent copy, light/dark/auto theming, AJAX-only flows (no page refresh, useful for SPAs and low-friction checkout funnels), and consent-withdrawal UX placement. These are the pieces that usually generate design and legal-review churn; the package pre-answers them.
• Market/roadmap input: Relevant if the roadmap includes ES-language sites, Spanish subsidiaries, or EU expansion where local regulators are stricter than your current baseline. Good input for deciding which market gets a compliant consent flow first.
• Risk budgeting: With 2 stars, 0 dependents, and a single-maintainer signal, this is a low-blast-radius, forkable dependency (MIT, small surface, front-end-heavy). It's appropriate for a non-core compliance helper, not for a platform-critical consent-of-record system.

When to Consider This Package

Consider it when most of these are true:

• The application is Symfony (verify the supported Symfony/PHP version matrix against your runtime before promising anything).
• Users are in Spain or the EU, and you need AEPD-2024-shaped behavior: granular categories, reject-as-easy-as-accept, and easy withdrawal.
• You have no dedicated CMP budget and no legal team demanding a vendor with a DPA and indemnities.
• Time-to-compliance matters more than depth: a first release within days, on a site where consent is not the product.
• You need multi-language consent copy and a themable UI your design system can live with.
• Your engineering team is comfortable reading and, if needed, patching a small MIT bundle — assume you may become the maintainer.

Look elsewhere when any of these are true:

• Laravel (or any non-Symfony) stack — the framework coupling is the dealbreaker, not the feature set.
• You need IAB TCF v2.2, Google-certified CMP status, or ad-tech ecosystem signals — this is not that.
• You need enterprise consent evidence: immutable audit logs, per-user consent history at scale, cross-device reconciliation, retention guarantees, SOC 2 / ISO artifacts, or a named support contact.
• Active maintenance and community are hard requirements — 2 stars, 0 dependents and a single recent release mean effectively bus factor 1. No security advisories process, no downstream testing population.
• Consent is core to monetization or regulated at a higher tier (health, finance, minors), where a legal-reviewed commercial CMP is the cheaper insurance.
• You require documented legal sign-off for each jurisdiction — the README's AEPD framing is the vendor's claim, not your counsel's opinion.

Adoption gate (ask before committing): Does it actually block non-essential cookies pre-consent, or only render a banner? Does it store consent records (timestamp, scope, version of the notice) sufficient for demonstrating compliance? Can you export/delete on request? Is the retraction control present on every page? Get answers from a 1-day spike, not from the README.

How to Pitch It (Stakeholders)

To executives (30 seconds): We have a Spain-specific consent obligation and a free, MIT-licensed Symfony component that covers the standard requirements — a consent banner with granular categories, an equally easy reject path, and a persistent "withdraw consent" button — plus multilingual and dark-mode support. For a Symfony product, this is roughly one to three days of engineering instead of a multi-sprint build or an annual CMP subscription. The trade-off is maturity: it is a small, single-maintainer project with essentially no adoption, so we should treat it as code we adopt and can fork, not a vendor we depend on. Recommendation: pilot it on one Spanish-facing Symfony property, keep the integration behind a thin internal interface so it can be swapped, and revisit a commercial CMP if we expand to ad-tech or need auditable consent records at scale.

To engineering: MIT, composer-installable Symfony bundle, AJAX-driven with no page refresh, Twig templates and config for categories/expiry/theming. Two things to verify in the spike: (1) that it enforces pre-consent cookie blocking rather than only collecting preferences, and (2) how consent is persisted, since that determines whether we can answer a subject-access or regulator request. Wrap it so the rest of the app never imports its classes directly — that keeps a future fork, replacement, or Laravel port from becoming a refactor. Do not adopt it for the Laravel services; it's Symfony-only.