Cookielaw Widget Laravel Package

Technical Evaluation

Architecture fit. friendsofvictoire/cookielaw-widget is not a Laravel package — it is a Symfony bundle built for Victoire DCMS, a Symfony-based digital content management system. It ships as a bundle registered through the Symfony kernel, renders via Twig, and depends on Victoire's widget/DCMS abstractions. Laravel has no bundle-registration mechanism, no Twig by default, and no concept of a DCMS widget. There is no service provider, no config publish tag, no facade — nothing that maps onto Laravel's package conventions. The functional payload is a cookie-consent banner: a small markup/CSS/JS fragment plus a cookie-presence check. That is the entire value surface, and it is trivially reproducible outside Symfony.

Integration feasibility. Effectively zero as a dependency install, low-to-moderate as an extraction exercise. The realistic path is to vendor the front-end assets and reimplement the consent state in a Blade partial plus a small JS module — at which point you have written the widget yourself and gained nothing from the package. A genuine integration would require standing up Symfony's event dispatcher and Twig bridge inside Laravel, which is disproportionate engineering for a banner.

Technical risk. High and asymmetric. Last release was September 2016 — roughly nine years without a commit, security review, or compatibility bump. The dependency tree will target Symfony 2.x/3.x and PHP 5.6/7.x era constraints, which will almost certainly conflict with modern Laravel (PHP 8.1+, Symfony 6/7 components used transitively). Two stars and zero dependents means no production validation, no community fork, no issue triage, and no signal that anyone has run this in the last several years. The dominant risk is not runtime failure but regulatory: a 2016-era banner predates GDPR enforcement practice, the CNIL guidance, the EDPB cookie banner taskforce recommendations, and the ePrivacy consent requirements. It almost certainly lacks granular purpose categories, reject-all parity with accept-all, consent logging/audit trail, consent renewal, and pre-consent script gating. Deploying it could create the appearance of compliance while failing the substantive test.

Key questions.

• Is the actual requirement "a dismissible banner" or "defensible consent management"? If the latter, this package cannot satisfy it regardless of porting effort.
• Do we need consent evidence (timestamp, scope, version, identifier) for audit or contractual obligations? If yes, a server-side consent record is required and this package provides none.
• Which jurisdictions are in scope — EU/EEA only, or also UK, Brazil (LGPD), California (CPRA)? Multi-jurisdiction logic is absent.
• Is there an existing organizational CMP contract (OneTrust, Cookiebot, Osano, Usercentrics)? If so, this is moot.
• Who owns the fork if we vendor it, and what is the patch SLA for a legally sensitive component?

Integration Approach

Stack fit. Poor. The bundle assumes Symfony Flex, the Victoire DCMS widget registry, Twig templates, and Symfony's asset pipeline. Laravel's equivalents (Blade, service container, Vite/Mix, view composers) have no bridge here. There is no supported coexistence story.

Migration path. Do not attempt a direct dependency install. The correct path is a harvest-and-reimplement:

1. Read the source and extract the banner markup, CSS, and the cookie get/set logic — treat the repository as a design reference, not a library.
2. Reimplement as a Blade component (<x-cookie-banner />) with the state held in a first-party cookie or localStorage, keyed to a policy version string.
3. Implement pre-consent gating: no analytics, marketing, or third-party scripts execute until the corresponding category is granted. This is the part the original package does not reliably provide and the part that carries the legal weight.
4. If audit evidence is required, POST consent decisions to a small Laravel endpoint and persist them (user/session id, timestamp, categories, policy version, IP where lawful).
5. Alternatively, adopt a maintained CMP and skip steps 2–3 entirely.

Compatibility. Composer resolution will likely fail outright on PHP 8.1+ / Laravel 10–12 due to Symfony constraint conflicts. Even if forced through with --ignore-platform-reqs, the bundle will not register and the Twig dependency chain will pull unused Symfony packages into production. Treat compatibility as a blocker rather than a tuning problem.

Sequencing. Front-load a half-day spike to confirm incompatibility and capture the asset list. Then decide build-vs-buy before writing code. If building: banner component → consent state module → script gating → consent logging → QA across locales and mobile. Total engineering estimate for the in-house build is small — on the order of one to three developer-days for a single-jurisdiction banner, more for granular categories and logging. That estimate should be compared directly against the cost of evaluating and integrating this package, which is higher with worse outcomes.

Operational Impact

Maintenance. This is the decisive factor. Zero upstream releases in nine years, a two-star repository, no dependents, and a single organizational maintainer whose DCMS project has itself gone quiet. Any use is a permanent fork: your team owns every line, every future browser quirk, and every regulatory change. For a component that sits directly in the path of privacy compliance, an unmaintained dependency is an unpriced liability.

Support. None available. Documentation is scoped to Victoire DCMS administrators, not integrators, and there is no issue triage, security disclosure process, or versioning discipline to rely on. Escalation paths are effectively "read the source."

Scaling. The banner itself does not scale-load — it is static markup and a cookie read, negligible against any traffic profile. The real scaling concern is organizational: a hand-rolled, single-jurisdiction banner does not extend cleanly to multiple brands, locales, or regulatory regimes without becoming an internal product with its own roadmap. That is a fine outcome if deliberately chosen, and a bad one if it arrives by accident.

Failure modes. Ranked by severity:

• Silent non-compliance — banner renders, consent is not actually enforced, scripts fire before consent. Highest severity, no runtime error to alert on, discovered in an audit or complaint.
• Dependency resolution failure — Composer conflict blocks install; detected immediately, low cost.
• Bundle registration failure — package present but inert; moderate cost, wasted integration effort.
• Consent-state drift — cookie versioning absent, stale consent honored indefinitely; moderate severity, surfaces only under scrutiny.
• Third-party blocking — if the banner's JS is served from an unvetted path or blocked by an extension, users see no banner and consent defaults to whatever the site does; must fail closed, not open.

Ramp-up. Time to understand the codebase is short — the widget is small and the logic is legible. But that low ramp-up cost is misleading: understanding it takes hours, and replacing it takes days. The package's real contribution is a reference implementation of a consent banner, and that contribution is worth roughly the effort of reading it.

Recommendation. Reject as a dependency. The score of 0.04 is consistent with the evidence: Symfony-only architecture against a Laravel target, nine years unmaintained, no dependents, and a compliance-sensitive function that a 2016 build cannot be expected to satisfy. Either build a small first-party Blade component with proper script gating, or procure a maintained CMP if consent evidence is required. Do not budget integration effort for this package — budget a spike to extract its assets and move on.