Cookie Bundle Laravel Package

Technical Evaluation

Architecture fit — the framework mismatch is the headline. Despite the "Laravel/PHP package" framing, eveltic/cookie-bundle is a Symfony bundle, not a Laravel package. It is built around Symfony conventions: a DI extension with a configuration tree, Twig templates and Twig extensions, Symfony routing/controllers for the AJAX consent endpoints, the Symfony Translator for multilingual strings, and event subscribers. None of that autoloads or boots inside a Laravel application without a compatibility layer. In a Symfony codebase this is a low-effort drop-in; in a Laravel codebase it is a reference implementation to port, not a dependency to install.

What the package actually is. Stripping the README down, the deliverable is: (a) a configurable consent banner UI with four default categories (technical, preferences, analytics, ads), theme support (light/dark/auto), and multilingual copy; (b) a preferences modal with per-category toggles; (c) a persistent "retract consent" affordance (floating button plus a consent-details view); (d) AJAX endpoints to persist and update preferences without a page reload; (e) configurable cookie expiration. That is a UI and preference-capture layer, not a full consent management platform.

Integration feasibility by hosting framework:

Technical risk:

• Vendor and abandonment risk (highest). 2 stars, 0 dependents, no visible community. The MIT license means you can fork, but it does not reduce the cost of owning the fork. Assume from day one that your team is the maintainer of record.
• Compliance is asserted, not evidenced. "Compliant with 2024 AEPD regulations" is a marketing claim, not a certification. AEPD/GDPR-ePrivacy compliance depends heavily on behaviors the README does not describe. The recurring gaps in packages of this shape are: scripts firing before consent is captured; no reject-all button with equal prominence; pre-ticked categories; no server-side proof-of-consent record (timestamp, policy version, categories, user identifier); no re-consent flow when the policy version changes; no per-vendor granularity where required.
• Consent persistence model is unknown. If preferences live only in localStorage/first-party cookies, you have a functional UX but weak evidentiary value. Ask explicitly whether there is a server-side consent log and what its retention policy is.
• Ecosystem interop. No stated support for Google Consent Mode v2 or IAB TCF. If the site runs GTM/GA4/AdSense, Consent Mode is effectively table stakes in the EU, and its absence turns this into custom glue work.
• Security surface. AJAX write endpoints for consent state need CSRF protection, input validation, and rate limiting. Inline bootstrap scripts for the banner frequently collide with a strict CSP; verify nonce/hash support.
• Accessibility. No mention of WCAG 2.2 AA, focus trapping in the modal, or keyboard/screen-reader behavior. Consent banners are a common accessibility failure point and increasingly a regulatory one.
• Maturity signals are thin. "readme, releases" with no CI badges, coverage reports, or detailed changelog. Last release 2025-09-26 suggests recent activity, but a single recent release is not a maintenance track record.

Key questions to put to the maintainer or resolve by code review:

1. Where is consent state stored — client, server, or both — and is there an auditable log with timestamp and policy/banner version?
2. Does the package block non-essential scripts before consent, or only record a preference while tags still fire?
3. Is there a reject-all path with equal prominence, and are all non-technical categories off by default?
4. Google Consent Mode v2 / TCF support — native, planned, or out of scope?
5. Which locales ship, and is the Spanish (AEPD) copy legally reviewed?
6. What are the PHP/Symfony version constraints, and is there a test suite?
7. How are policy-version changes handled — forced re-consent, or silent carry-over?
8. Is a Laravel port on the roadmap, or is Symfony-only a permanent constraint?

Integration Approach

Stack fit. Resolve the framework question before anything else. If the target is Laravel — which the brief implies — treat this repository as donor code, not a dependency. Its value is the UX patterns (retract-consent floating button, consent-details drawer, category model), the copy, and the DOM/JS structure. That value is real and reusable; the Symfony plumbing is not.

Options, ranked:

1. Hosted CMP (Cookiebot, Usercentrics, CookieYes, Osano). Fastest path to defensible compliance: audit logs, Consent Mode, TCF, geo-targeting, and a vendor who owns regulatory change. Cost is per-pageview licensing and a third-party script. Best when the compliance surface is broad or the team is small.
2. Port to a first-party Laravel package. Extract Twig→Blade, move config to config/cookie-consent.php, implement two or three routes in routes/web.php with a thin controller, reuse the CSS/JS assets, and add a consent_events table. Roughly 1–3 weeks for one developer including tests. Recommended if Laravel and you want no ongoing vendor fee.
3. Adopt as-is inside Symfony. Only viable if the product is Symfony. Low cost, still requires the consent-logging work above.
4. Fork and maintain. Choose deliberately, not by default. Pin the commit, vendor the assets, and assign an owner.

Migration path. If there is no existing CMP, this is greenfield — no data migration, just a banner-version field so future policy changes can force re-consent. If replacing an existing CMP, do not attempt to import old consent records into the new schema; the legal basis and category mapping rarely line up. Plan a clean re-prompt on a dated cutover, and keep the old records read-only for the limitation period.

Compatibility. Verify composer.json constraints against your PHP runtime and Symfony/Twig versions before committing. On the browser side the risk is CSP and ad-blockers rather than legacy browsers. If assets are served through a CDN, confirm cache-busting on banner-version changes.

Sequencing:

1. Week 0 — legal/DPO defines the requirement set (categories, reject-all, re-consent, retention, audit fields). Do this first; it determines whether the package is adequate at all.
2. Week 1 — 2-day spike: stand the bundle up in a Symfony sandbox or port a minimal Banner+Preferences slice into a Laravel branch. Measure real effort.
3. Week 1 — script-blocking audit of the tag manager: enumerate every tag and its category. This is consistently the largest hidden task.
4. Week 2 — decide adopt / port / buy against the spike result.
5. Weeks 2–4 — implement consent logging server-side, branding, and accessibility pass.
6. Week 4 — staging rollout with tag-assistant verification that no non-essential tag fires pre-consent.
7. Post-launch — re-consent runbook and a documented owner for the fork.

Operational Impact

Maintenance. Assume ownership. Budget roughly 1–2 engineer-days per quarter for dependency bumps and a yearly review against AEPD/GDPR guidance changes, plus translation upkeep for each locale you ship. Track the upstream repo; if it goes quiet for two release cycles, formally fork and record that decision.

Support. No vendor, no SLA, GitHub issues only. Stand up an internal runbook covering: how to add a category, how to add a locale, how to bump the policy version and trigger re-consent, and what to do if the banner fails to render. Name a single owning team — consent infrastructure fails organizationally when it is "everyone's."

Scaling. Runtime cost is negligible: static CSS/JS plus infrequent AJAX writes at consent time. The real scaling concerns are (a) write volume and bot noise on the consent endpoint — rate-limit it and consider dropping obvious bot traffic; (b) CDN staleness serving an outdated banner after a policy change; (c) consent-record table growth — partition or archive per your retention policy.

Failure modes to design against:

• Banner JS blocked by CSP or an ad-blocker → no consent captured, but tags may still fire. Mitigate with server-side default-deny and a fail-closed tag loader.
• AJAX endpoint 4xx/5xx → UI shows "saved" while nothing persisted. Make the write path optimistic-UI plus verified, and surface a retry.
• Silent regression: a developer adds a tag outside the consent gate. Prevent with a CI check or tag-manager review in the definition of done.
• Policy version bump without re-consent → stale consent treated as current. Encode the version in the record and compare on load.
• Stored preferences cleared → must default to deny, never to prior-accept.

Ramp-up. A Laravel team needs 1–2 days to read the Symfony code comfortably (bundle extension, Twig, service tags) — mostly to distinguish reusable assets from framework glue. Add half a day of consent-law literacy for whoever owns the integration: the failure mode here is not technical, it is shipping a technically correct banner that captures the wrong thing. Total onboarding for a port: roughly one engineer-week before productive output, against a 1–3 week implementation.