Cookie Bundle Laravel Package

Product Decisions This Supports

• Scope definition for a consent experience. The bundle still describes three concrete artifacts a PM has to spec anyway: a cookie bar (first-layer notice + accept/reject), a preference pop-up (per-category toggles), and a cookie policy page explaining each cookie. That remains a usable checklist for writing acceptance criteria, even if you never install the package.
• Build vs. buy vs. borrow. The "borrow" case has weakened, not strengthened. Release 1.7.0 is the final 1.x release, and the upgrade path points at a 6.0 line — meaning the project is alive, but versioned in lockstep with a CMS release train we don't run. The honest comparison is now "2–4 engineer-days to replicate" versus "adopt a dependency whose next supported version requires a major framework migration we have no reason to take." That still pushes toward build-in-house or buy-a-real-CMP.
• Compliance roadmap sequencing. The bundle's feature boundary remains a clean line between "MVP notice" and "actual consent management": Phase 1 (inform + collect preference) is in scope; Phase 2 (block tags pre-consent, store consent records, geo-targeting, re-consent on policy change) is not. The 1.x → 6.0 jump does not add any of these — it is housekeeping, not capability.
• Framework fit diligence. Kunstmaan bundles target Symfony and the Kunstmaan CMS ecosystem, not Laravel. The release cadence (1.x now closed, 6.x current) reinforces this: versioning tracks the host CMS, so adopting it means adopting a slice of their release calendar. This is a port, not a drop-in — flag it before anyone spends a spike on it.
• Vendor-risk recalibration. The prior read — "abandoned 2021 dependency" — is no longer accurate and should be retired from the deck. The accurate risk statement is "actively maintained, but only on a major version we can't consume, and only for a framework we don't use." That is a fit problem, not an abandonment problem, and it's a stronger argument because it doesn't depend on star counts or release dates going stale.

When to Consider This Package

Adopt only if all of the following hold:

• You are already on Symfony and specifically within the Kunstmaan CMS bundle ecosystem, and you are on (or migrating to) the 6.x line — 1.7.0 is explicitly the end of the 1.x branch, so starting there means starting on an EOL version.
• You need only informational consent: a bar, a category preferences modal, and a static policy page. No script blocking, no consent logging, no IAB TCF, no Google Consent Mode v2 signaling.
• You have read the UPGRADE-6.0 notes and the migration cost is genuinely near zero for you — not "we'll deal with it later."
• Your legal review has signed off on a notice-only pattern for your jurisdictions.

Look elsewhere — or build — if any of these are true:

• You need consent enforcement (tags suppressed until opt-in), consent receipts/audit trail, versioned policy re-consent, or region-specific behavior. Those are CMP features; evaluate OneTrust, Usercentrics, Cookiebot, or Osano, or build a ~300-line consent manager around a tag loader you control.
• You're on Laravel. The porting effort erases any savings, and you'd inherit a CMS-coupled upgrade cadence without any of the integration benefit. The 6.0 migration is a cost you'd pay for nothing.
• Anyone proposes pinning 1.7.0. It is the terminal 1.x release by the maintainers' own statement — no further patches on that branch. Do not let "last release" get misread as "stable release."
• You need accessibility conformance, i18n beyond the bundled translations, or design-system alignment — you'll be rewriting the front end regardless.

Net: this is a reference implementation, not a dependency — and the 1.7.0 note makes that framing sharper, not softer, because the reusable part (cookie taxonomy, preference model, template structure) is version-independent while the consumable part now requires a framework and a major-version migration we don't want.

How to Pitch It (Stakeholders)

To executives: This is a small, free cookie-notice component from the Kunstmaan CMS ecosystem. Its latest release, 1.7.0, is explicitly the last release on its current major version — the project is maintained, but only going forward on a 6.x line tied to a CMS we don't run. So the cost isn't a license fee, it's a framework migration plus an ongoing dependency on someone else's release calendar. And it still doesn't deliver compliance: no pre-consent script blocking, no consent evidence, no regional targeting. My recommendation is unchanged — use it as a design reference and either build a lightweight consent layer in-house (roughly 3–5 engineer-days) or license a dedicated CMP if we need enforcement and audit trails. I'd also ask that we stop describing this as an "abandoned" package in any deck; the accurate objection is fit, not neglect.

To engineering: Symfony bundle, Kunstmaan CMS family, not Laravel-compatible. Release 1.7.0 contains only upgrade documentation and closes the 1.x branch — there is no functional change, no security fix, no new feature. The 6.x line is where development continues; its versioning tracks the host CMS, so consuming it means tracking their majors. Surface area is still small: a cookie bar, a preferences modal, a policy page, a category model. Don't add it as a dependency, and specifically don't pin 1.7.0 as a "final stable" — it's EOL by the maintainers' own statement. Spend half a day reading the category/preference model and the front-end templates, then implement our own view layer over a consent store we control, so script blocking and consent logging can be added without a rewrite. If we ever do vendor it, it's a fork with a named owner and a pinned version — and it'd be the 6.x branch, not this one.

Recommendation: Decline as a dependency. Reuse as a spec and UX reference. The 1.7.0 release changes the reason (framework/release-train coupling and 1.x EOL, rather than abandonment) but not the conclusion. Budget a small in-house build now, and revisit a commercial CMP only if legal or regional requirements escalate.