Cookie Guard Bundle Laravel Package

Product Decisions This Supports

• Whether to build or buy consent management. This package still addresses only one slice of a real, non-optional product need: withholding third-party scripts (analytics, ad pixels, chat widgets, embedded video/maps, A/B testing tools) until the user grants cookie consent. The gating logic itself remains commodity — the durable value is in consent capture, storage, audit, and reporting, which this does not cover.
• Architecture choice for script activation. Two viable patterns: (a) server-render <script> tags with type="text/plain" or data-* attributes and swap them client-side after consent, or (b) defer entirely to a client-side tag manager/CMP with built-in blocking. This package is pattern (a). Pattern (a) leaks less third-party JS before consent but requires you to own the inventory and the swap logic.
• Roadmap prioritization for compliance work. Use it as a reference implementation when scoping a "GDPR / ePrivacy / CCPA readiness" epic, and to argue that the epic is larger than "gate the scripts" — it also needs consent records, withdrawal handling, jurisdiction rules, and evidence for auditors.
• Vendor/tooling shortlist hygiene — reassess the rejection rationale. The prior rejection leaned heavily on "archived, no patch cadence, last release 2022-11-25." The 2.0.0-rc release invalidates that specific argument: the project is shipping again. The rejection should be re-grounded on the durable reasons (wrong framework, no consent management, no audit trail), not on abandonment. Keep a dated note in the "evaluated and rejected" list recording what changed and why the conclusion held.
• Release-readiness and dependency-risk judgment. A major version bump (1.3.0 → 2.0.0) means breaking changes, and it is shipping as a release candidate, not stable. A major release published with no described changes is itself a governance signal for privacy-critical code — you cannot scope an upgrade path from "Full Changelog" alone. If any team is on 1.x, treat this as a planned migration, not a patch.
• Stack-fit filtering. The material mismatch is unchanged: this is a Symfony bundle, not a Laravel package. No service provider, no config publishing, no Blade integration — a pattern to copy, not a dependency to install.

When to Consider This Package

Consider it only under a narrow set of conditions:

• You are running Symfony (the bundle's actual target), not Laravel, and you want a minimal, self-hosted script-gating mechanism rather than a commercial CMP.
• Your third-party script inventory is small and stable (a handful of analytics/marketing tags), and you have engineering capacity to fork and maintain it yourself.
• You need a code-reading reference for how attribute-based script deferral works — a few hours of reading, not a dependency.
• Your compliance obligation is genuinely just "don't load scripts before consent," with no requirement for consent receipts, IAB TCF strings, geo-targeted banners, or vendor lists.

Look elsewhere when:

• You are on Laravel. There is still no first-class integration; you would be porting a Symfony bundle, at which point writing ~100 lines of a Blade directive plus a small JS gate is cheaper and clearer.
• You need a stable, supported dependency. 2.0.0-rc is a pre-release. The 2.0.0 changelog is undocumented in the release notes, the release cadence before this was a multi-year gap, and adoption remains negligible. Consent code touches privacy law and third-party script injection — wait for a stable tag and readable release notes before treating this as maintained.
• You need real consent management. No consent persistence, no audit log, no versioned policy, no preference center, no TCF/Google Consent Mode support. A commercial or actively maintained open-source CMP (OneTrust, Usercentrics, Cookiebot, Osano, or an OSS alternative) covers these.
• Marketing owns tag deployment. If tags change weekly via a tag manager, static server-side gating becomes a bottleneck; a CMP with tag-manager blocking is the better fit.
• You need proof for an auditor or DPA. This package produces no evidence trail.

Follow-up action: re-read this assessment when 2.0.0 stable lands with an actual changelog. If that release adds consent persistence, policy versioning, or a documented migration path, the build-vs-buy calculus changes and this deserves a fresh evaluation rather than an inherited "rejected."

How to Pitch It (Stakeholders)

Recommendation: still do not adopt for our Laravel codebase — but soften the framing from "abandoned" to "wrong fit, immature release."

• To executives: The underlying problem — not loading tracking scripts before a user consents — is real and legally required in the EU/UK and increasingly elsewhere. This package is now actively releasing again (a new 2.0.0 release candidate), so the "abandoned project" objection no longer holds. The reasons not to use it are different and still decisive: it targets a framework we don't run, it's a pre-release with undocumented breaking changes, and it does none of the consent-management work — records, withdrawal, reporting — that regulators actually ask about. The realistic options are unchanged: a maintained consent-management vendor (budget line, roughly days of integration) or a small in-house gate (~1–2 engineering days) we own and can audit.
• To engineering: It's a Symfony bundle, not Laravel, so it still doesn't drop in. 2.0.0-rc is a major version with no described changes, so we can't assess upgrade risk or feature delta from the release notes alone. The pattern remains simple enough to reimplement in an afternoon: render non-executing <script type="text/plain" data-consent-category="..."> tags, keep a category-to-consent map, and on consent change, clone and inject the approved tags. Owning that code is lower risk than adopting a pre-release dependency, and it lets us integrate directly with whichever CMP we pick. If anyone wants to revisit at 2.0.0 stable, the ask is: read the changelog, confirm no TCF/audit features are needed, and bring a maintenance-ownership proposal.
• To legal/compliance: No change to the conclusion. We can gate scripts before consent, but we cannot produce consent receipts or versioned proof with this approach alone. Confirm what evidence standard applies before we scope the build.