Cookie Bundle Laravel Package

Technical Evaluation

Architecture fit

The category mismatch still gates everything: kunstmaan/cookie-bundle remains a Symfony bundle, not a Laravel package. Release 1.7.0 changes nothing here — the changelog is a single documentation entry ("Added upgrade info"). It ships a KunstmaanCookieBundle class, a DependencyInjection extension with a configuration tree, Twig templates, and service definitions wired through Symfony's container. No service provider, no Blade views, no Laravel config publishing, no facade.

Functionally it delivers three artifacts: a persistent cookie bar, a preference pop-up, and a cookie policy page enumerating cookie categories. That is a presentation-layer plus configuration concern, not a consent-management backend. Still no evidence of server-side consent persistence, consent-versioning, audit logging, or pre-consent script blocking — the parts that carry compliance weight.

Integration feasibility

Into Laravel: still not feasible as a dependency. Composer may resolve it, but Laravel's kernel never registers the bundle, so routes, Twig rendering, and container wiring stay inert. Integration means fork-and-port or reuse-as-reference.

Into Symfony: feasible but version-constrained, and 1.7.0 makes that constraint sharper. The release is explicitly flagged as the last 1.x release, with an UPGRADE-6.0.md pointing to a version realignment with the Kunstmaan CMS 6 line. So the practical question is no longer "does 1.x install on Symfony 6/7?" but "does the 6.0 line, and on what Symfony major?" — and 6.0 is unreleased at time of writing. Committing to 1.7.0 today means committing to a line the maintainer has just declared end-of-life.

Technical risk

• The 1.x line is now formally frozen. 1.7.0 is a lifecycle announcement, not a maintenance release: zero code changes, therefore zero security fixes. Any advisory affecting 1.x dependencies accumulated since the previous release remains unpatched on this line, and no further 1.x patches should be expected.
• A breaking major is pending but unquantified. UPGRADE-6.0.md implies container/config signature changes. We cannot yet assess migration cost, Symfony major support, or whether the front-end assets are modernized. Planning against an announced-but-unreleased breaking version is a schedule risk.
• Staleness in a legally load-bearing domain. The codebase's last functional change predates or misses current EDPB guidance interpretations, CNIL-style reject-button parity, Google Consent Mode v2, and TCF vendor handling. A version bump that adds only a doc link does not close any of that.
• Zero downstream validation. No public consumer base exercising the code, no issue backlog, no community patch velocity. The 1.7.0 release does not create signal — it confirms the maintainer is closing the line rather than investing in it.
• Transitive weight. Depending on kunstmaan/bundle-class packages pulls additional Symfony surface area, each with its own advisory exposure — now with no upstream patching on this line.
• Cosmetic-consent trap. If the bundle only renders a bar without intercepting script injection, deploying it creates a false sense of compliance — worse than no banner in an enforcement action.

Key questions

1. Does the 6.0 line ship a Symfony 6/7-compatible release, on what date, and is it a rewrite or a constraint bump?
2. Does the bundle block non-essential scripts/cookies before consent, or only display a notice?
3. Is consent recorded server-side with timestamp, policy version, and scope, sufficient for an audit trail?
4. Is there any maintainer commitment to security patches for 1.x post-1.7.0, or is the line unsupported as of this release?
5. Can 1.7.0 be pinned safely, or does the "last 1.x" flag make it unpinnable from a supply-chain standpoint?
6. Is the license permissive enough to fork and maintain privately, and who owns that fork?
7. Does any requirement mandate a certified CMP (TCF, IAB) rather than a homegrown banner?

Integration Approach

Stack fit

Unchanged: poor for Laravel, moderate for Symfony. The bundle assumes Twig rendering, Symfony asset/translation conventions, and container-managed configuration. A Laravel codebase would need the concepts translated: Twig → Blade components, DI config → config/cookie.php, bundle routes → Laravel routes, cookie persistence → middleware plus a table-backed consent log.

Migration path

Still treat this as a reference implementation, not a dependency — 1.7.0 reinforces that stance by closing the 1.x line. Concretely:

1. Short spike (3–5 days): read the bundle source, extract the cookie-category model, bar/modal interaction pattern, and copy structure.
2. Reimplement as a first-party Laravel package: Blade components, a cookie_consents table (user/session, policy version, categories granted, timestamp, IP hash), middleware for consent state, and a policy page driven by a config-declared cookie registry.
3. Wire pre-consent blocking explicitly — tag-manager consent-mode config or script-tag gating is mandatory.

If the host app is Symfony, the calculus has shifted. On 4.4/5.x, 1.7.0 is installable and pinning it is defensible only with a named internal owner, because no patches follow. On Symfony 6/7, 1.7.0 is not a viable target — either wait on 6.0 with a dated go/no-go, or fork 1.x and bump constraints yourself.

Compatibility

Confirm PHP floor and Symfony major support — and treat the 6.0 upgrade file as the authoritative forward-looking document. Expect Twig syntax and deprecated service-definition patterns to need edits on modern stacks, and note that the 6.0 realignment may change bundle naming and config keys, so do not build integrations that hardcode 1.x service IDs. Front-end assets remain unversioned and non-npm, so Vite/Encore bundling requires extraction.

Sequencing

Discovery spike → read UPGRADE-6.0.md and record what breaks → legal/DPO requirements elicitation (what must be logged, re-prompt cadence, reject parity) → build-vs-buy gate → if build, port the package and consent store → integrate blocking/consent-mode → DPO sign-off → staged rollout behind a feature flag. Add one gate this cycle: decide fork-vs-wait-6.0 before writing code, since 1.7.0 is the last release you can fork from a "current" baseline. Do not sequence the banner before the blocking mechanism.

Operational Impact

Maintenance

Forking transfers full maintenance to us: Symfony/Twig upgrades, security advisories in transitive dependencies, front-end asset upkeep, translation drift, and regulatory copy. 1.7.0 confirms upstream is in wind-down for 1.x — the release is a signpost, not a repair. Expect zero 1.x help. Budget 2–5 days annual upkeep plus ad-hoc regulatory updates, and plan for a one-off jump to 6.0 if you ever intend to track upstream again.

Support

No vendor support, no SLA, no active community, and now a stated end-of-life for the line we would be deploying. Internal ownership must be assigned at adoption, and the "last 1.x" status should be recorded in the dependency register so future maintainers do not assume an upgrade path exists.

Scaling

Runtime scaling is a non-issue — client-side and cacheable. The scaling concern is data: consent logs grow monotonically and must be retained as evidence, so plan partitioning/retention up front. Also watch CDN/page-cache interaction: cached HTML can serve stale banner state or a stale policy version, silently skipping re-prompt.

Failure modes

• Banner JS fails to render (asset pipeline, CSP, ad blocker) → scripts execute without consent → reportable incident.
• Consent state stored client-side only → no defensible audit trail.
• Policy version bumps without re-prompt logic → existing consents silently invalid.
• Transitive Symfony advisory lands with no 1.x patch available → forced emergency fork or emergency migration to 6.0 on the maintainer's timetable, not ours.
• 6.0 lands with different config/service contracts while we are mid-integration against 1.7.0 → rework.
• Translation/copy gaps on non-default locales → consent not "informed" in that jurisdiction.
• Consent Mode / tag manager misconfiguration → analytics fires pre-consent behind a compliant-looking banner.

Ramp-up

Engineering: 1–2 days to read the Symfony source competently; ~2–4 weeks to port and harden a Laravel equivalent including blocking integration and tests; add a day to digest UPGRADE-6.0.md and record the fork decision. Legal/DPO: one review cycle to define logging requirements and copy. The recommendation is unchanged and slightly firmer: do not adopt as a dependency — 1.7.0 closes the 1.x line without shipping fixes — mine it for interaction and content patterns, and build or buy a consent mechanism that actually blocks and records.