Cookie Consent Bundle Laravel Package

Technical Evaluation

Architecture fit — fundamental mismatch with the stated stack. The package is a Symfony bundle, not a Laravel package. Its entry point is a Symfony\Component\HttpKernel\Bundle\Bundle subclass registered via config/bundles.php, with services wired through a DI extension and Twig templates. Laravel has no bundle registry and its package auto-discovery only recognizes Illuminate\Support\ServiceProvider. composer require lemric/cookie-consent-bundle in a Laravel app will install files that never boot. The only Symfony surface Laravel shares is a handful of decoupled components (HttpFoundation, Console, Process) — not the HttpKernel event system or the container compilation this bundle depends on.

Integration feasibility. In a genuine Symfony application: feasible and small — enable the bundle, configure consent categories, override Twig templates, gate script tags on the consent state. In a Laravel application: not feasible as-is. A wrapper ServiceProvider that manually binds the bundle's services is a dead end, because the bundle's controller and event subscribers rely on Symfony kernel events and container conventions Laravel does not dispatch. The realistic path is a fork of the consent-storage and banner logic into a native Laravel package (ServiceProvider + Blade component + middleware + config), roughly 2–4 engineer-days of work.

Technical risk — concentrated in compliance, not code. This is a legal-risk surface. The package's stated purpose is AVG/GDPR compliance, but at 0 stars and 0 dependents there is no evidence of external review of its consent semantics. Specific unknowns that a DPO will ask about: whether it blocks cookies and scripts prior to consent or merely renders a banner (banner-only tools are the most common false sense of compliance); whether it persists a consent record with timestamp, policy version/hash, and categories granted; whether consent is revocable and re-prompted on policy change. Supply-chain risk is also elevated: single maintainer, no dependents, no visible community — an unmaintained dependency sitting directly on a regulatory obligation.

Key questions for the maintainer / spike.

• Does the bundle prevent cookie/script execution pre-consent, or only display a notice?
• Is consent recorded server-side (audit trail), and is the record versioned against the privacy policy?
• Are granular categories, withdrawal of consent, and re-consent on policy change supported?
• What are the declared Symfony and PHP version constraints, and is there CI/test coverage?
• Is there a framework-agnostic core, or is the logic entangled with Twig and the Symfony container?
• Does the maintainer offer any support commitment, or is this effectively abandonware with an MIT license?

Integration Approach

Stack fit. This package fits only Symfony 5/6/7 projects. For a Laravel-first organization it is the wrong artifact entirely. The credible alternatives are framework-native packages (spatie/laravel-cookie-consent, whitecube/laravel-cookie-consent) for the banner layer, or a hosted CMP with a contractual DPA (Cookiebot, Osano, Usercentrics, OneTrust) for defensible compliance evidence. Note that the banner is the cheap half of the problem; script blocking and consent logging are the parts that carry the legal weight.

Migration path. Symfony: composer require, register in bundles.php, configure categories, publish/override Twig templates, wire consent checks into each third-party script tag, verify with a cookie scanner. Laravel (recommended): do not wrap — fork. Lift the consent decision logic and cookie payload into a first-party package, replace Twig with Blade, replace the kernel subscriber with middleware, replace bundle config with config/cookie-consent.php. Treat the upstream repo as a reference implementation, not a dependency. MIT licensing makes this clean from an IP standpoint.

Compatibility. Verify PHP version floor, Symfony constraint range, and Twig dependency before anything else. If the repo pins symfony/framework-bundle to a narrow range, the fork-and-adapt cost rises. In a Laravel context, also check for conflict with the app's existing middleware stack, session driver, and any edge/CDN caching that would serve a stale banner state across users.

Sequencing.

1. Resolve the framework question first — confirm whether the target codebase is actually Symfony or Laravel; the entire recommendation pivots on this.
2. Complete the cookie inventory and data mapping with legal/DPO before evaluating any tooling. Tool selection without an inventory is backwards.
3. Timebox a 2-day technical spike: fork the consent logic, stand up a banner in the target framework, prove pre-consent script blocking.
4. Make an explicit build-vs-buy call, including the hosted-CMP option with procurement and DPA review.
5. If building, implement consent logging and withdrawal before launch, not after.
6. QA with an automated cookie scanner across locales, logged-in/out states, and cache-warm paths.

Operational Impact

Maintenance. Assume you own this code. At 0 stars and 0 dependents there is no community to absorb upgrades, and a single maintainer is a bus-factor of one. Budget for an internally maintained fork with a named owner. Positively, the MIT license and small surface area mean the fork is cheap to carry; a few hundred lines of consent logic is not a heavy long-term liability. Track upstream for security patches, but do not assume they will arrive.

Support. No SLA, no vendor contact, no compliance attestation. GitHub issues only. Any question your DPO or outside counsel raises about consent semantics will be answered by your own engineers reading the source. That is acceptable for a banner; it is uncomfortable for the system of record for regulatory consent.

Scaling. Runtime cost is negligible — a cookie write and a template render. The real scaling considerations are non-functional: server-rendered banners interact poorly with full-page CDN caching (a cached page can pin one visitor's consent state for everyone), and multi-domain, multi-locale, and subdomain-sharing configurations each need explicit cookie Domain/SameSite decisions. If you add server-side consent logging, that becomes a write path with retention and PII-handling obligations of its own.

Failure modes.

• Silent non-compliance: banner renders, but third-party scripts fire before consent — the worst outcome, because it looks compliant and isn't.
• Consent drift: policy updated, stored consents not invalidated or re-prompted.
• Cache contamination: CDN serves a banner state or nonce that doesn't match the visitor.
• CSP breakage: inline consent JS blocked by a strict Content-Security-Policy, leaving the banner non-functional.
• Upgrade breakage: a Symfony major bump lands and the unmaintained bundle no longer compiles; template overrides silently lost on update.
• Abandonment: repository goes quiet, and a compliance-critical dependency sits unpatchable in the tree.

Ramp-up. Low for a Symfony developer — a day to integrate and template. The effort is not engineering; it is the cookie inventory, legal review, and DPO sign-off, which run in weeks and are entirely unaddressed by this package. Frame the estimate accordingly: this is a compliance program with a small tooling component, not a library adoption with a small legal component. At 0.2 overall score with zero adoption signals, the honest recommendation is to treat this as a reference implementation to fork, or to skip it in favor of a supported CMP — not to adopt it as a dependency.