Cookie Guard Bundle Laravel Package

Technical Evaluation

Architecture fit — primary blocker, unchanged. The new 2.0.0-rc does not alter the fundamental finding: freshheads/cookie-guard-bundle is a Symfony bundle, not a Laravel package. It ships DependencyInjection/, Resources/config/, and Twig-extension wiring that depend on the Symfony kernel, its config tree loader, and the Symfony EventDispatcher. No major-version bump changes the framework it targets — a Laravel port is still required. Laravel has no bundle system: it has service providers, facades, Blade directives, and a different container/config model. There is no drop-in path at any version.

What's new in this release. Effectively nothing we can use. The release notes are a title and an auto-generated compare link (1.3.0...2.0.0-rc) with no changelog body, no breaking-change list, no deprecations, no migration guide, and no compatibility matrix. We cannot determine from the published notes whether 2.0.0 adds PHP 8.3/8.4 support, moves to Symfony 6/7, changes the consent-category model, rewrites the client-side script promotion, or is a CI/tooling-only bump. Treat the release as an unverified signal, not as evidence of renewed maintenance.

What is actually reusable. Unchanged: the domain logic is small and portable — a registry of cookie-consent categories, a mechanism to render external scripts as inert <script type="text/plain" data-cookie-consent="..."> tags, and a client-side listener that promotes those tags to live <script> elements on consent. ~200–400 lines. The Symfony plumbing is not reusable. If 2.0.0 rewrote the front-end listener, the reference implementation we would copy is now the 2.0.0-rc tree, not the 1.3.0 tree — which means our porting baseline just moved and is, by definition, a release candidate.

Integration feasibility. Unchanged — feasible only as a port: service provider + config/cookie-guard.php replacing the Symfony config tree, a Blade directive (@cookieGuard('marketing')) replacing the Twig extension, a published JS asset replacing the bundle's front-end listener. 1–2 engineer-weeks including tests, docs, and a compatibility matrix against the existing CMP.

Technical risk — still elevated, but the risk profile has shifted.

New risk introduced by this release. A 2.0.0-rc published after years of dormancy with an empty changelog is itself a governance signal. Two failure trajectories: (a) the RC never reaches GA — the project stalls mid-bump, leaving us referencing a pre-release; or (b) it does go GA with undocumented breaking changes, and any code we extracted from 1.3.0 must be re-baselined against an unannounced behavior change. Either way, our copy of the pattern is now pinned to a moving, undocumented target.

Key questions for the team.

1. Which CMP is already in place (Cookiebot, OneTrust, Osano, Klaro, custom)? Most provide native script blocking; if so this package is redundant at any version.
2. Is our front end Blade-rendered, or a JS SPA/Vue/Inertia app? Tag-rewriting remains fragile under SPA route changes and full-page caching.
3. Do we need consent withdrawal and category-level granularity, or just a single accept gate?
4. New: What is actually in 2.0.0? Pull the commit range and diff the consent model and JS listener before anyone reads this as "the project is alive."
5. New: Are we porting from 1.3.0 or 2.0.0-rc? Decide deliberately; do not default to latest.
6. New: Is the repo still archived, is there a named maintainer, and is there a stated GA date for 2.0.0?
7. Who owns the fork, and what is the deprecation path if we later switch CMPs?

Recommendation: unchanged in substance. Do not adopt as a dependency. The score (0.105), the Symfony-not-Laravel mismatch, and the compliance failure mode are all untouched by a version bump with no changelog. The abandonment finding is now unverified rather than confirmed, which weakens the strongest argument against the package but does not create an argument for it. Either (1) use the CMP's native blocking, or (2) fund a 1–2 week internal Laravel port. Add a 30-minute verification task to the discovery step: confirm repo status, read the actual 1.3.0...2.0.0-rc diff, and record whether 2.0.0 supports our PHP/Laravel target. Decide before sprint commitment.

Integration Approach

Stack fit. Poor out of the box, acceptable after porting — identical to the prior assessment. A 2.x bump to a Symfony bundle does not move it closer to Laravel. Mapping table for the port:

Migration path. Still no migration — nothing is installed today, and the 2.0.0-rc does not create an upgrade obligation because we have no dependency to upgrade. The path remains extract-and-rewrite: copy the consent-tag-rewriting JS and category model, discard all Symfony wiring, reimplement the PHP side idiomatically. Do not attempt a Symfony-emulation shim.

Compatibility — needs re-baselining. Previously we flagged that the archived code targeted PHP 7.x/8.0-era and Symfony 4/5. That assertion is now provisional. If 2.0.0-rc modernizes the PHP and Symfony floor, the extracted JS and category model may be cleaner to lift; if it also changes the public JS contract (attribute names, event names, storage keys), copying from it silently changes our integration surface. Verify before writing code:

• PHP floor and Symfony floor stated in composer.json at the RC tag.
• Whether data-cookie-consent attribute naming and the promotion event survived 2.0.0.
• Whether the JS is still dependency-free or now assumes a build step.
• CSP remains the largest unknown: inline <script type="text/plain"> blocks and runtime tag injection interact badly with strict script-src and nonce policies — unchanged by any version.

Sequencing.

1. Discovery (2–3 days, was 2–3 days): confirm CMP in place and whether native blocking already covers the requirement — kill here if it does. New sub-task (~30 min): verify 2.0.0-rc reality — repo archive status, maintainer, commit activity, dependents, and a read of the actual 1.3.0...2.0.0-rc diff. Record findings; do not infer health from a version number.
2. Spike (3–5 days): port the tag-promotion JS from a deliberately chosen baseline (1.3.0 or 2.0.0-rc), validate against CSP, full-page cache, and SPA navigation; test consent withdrawal.
3. Build (1 week): service provider, config, Blade directive, Pest/PHPUnit coverage, published asset.
4. Rollout (1 week): stage behind a feature flag, audit network requests with a consent-denied browser profile, then per-page enablement.

Build vs. buy — still effectively build, with a caveat. The RC does not convert this into an integration task. If discovery finds an active maintainer and a credible GA path, there is a narrow argument for tracking upstream as a reference implementation and re-syncing the ported logic — but only if the JS contract is stable and documented, which the empty changelog does not demonstrate. Budget as build and set stakeholder expectations that "adopting the package" is a misnomer at 1.x and at 2.0.0-rc alike.

Operational Impact

Maintenance. We still inherit ~100% of the burden. The 2.0.0-rc softens but does not resolve the ownership question: an RC is not a support commitment, and a release candidate with no changelog gives us no CVE feed, no deprecation notices, and no upgrade notes. Budget a modest recurring allocation (a few days per year) plus a named owner. If no owner is assigned, do not proceed. New: if the RC does reach GA, add a light quarterly check against upstream to catch consent-model or JS-contract drift — cheap insurance, and cheaper than discovering a divergence during a compliance audit.

Support. None from upstream. No issue triage evidence, no community, no CVE process. Internal support only. Acceptable for ~300 lines of well-tested internal code; unacceptable if treated as a third-party dependency on the assumption someone else is watching it. The RC does not change this.

Scaling. Effectively free and unchanged. Client-side tag promotion plus a PHP-side registry — no runtime cost, no database, no external calls, no throughput concerns. Scales with the front end, not the package. Full-page-cached HTML still ships the inert tags correctly, since consent resolution happens entirely in the browser.

Failure modes — ranked, with the RC's additions marked:

• Silent pre-consent tracker load (compliance breach). Mitigate with automated network-request assertions in a consent-denied browser profile in CI, per page template. Unchanged and still #1.
• Consent desync across tabs/returns — needs a storage-event listener; the archived bundle likely does not handle this. Check whether 2.0.0-rc addressed it.
• Withdrawal not honored — scripts already promoted stay live without a page reload.
• CSP violation — injected scripts blocked by script-src, producing a guard that "works" but loads nothing.
• Analytics/functional regressions post-rollout (consent default misconfigured, scripts never promoted) — visible only in revenue/telemetry drop-off, often days later.
• New — pre-release dependency drift. Porting from an RC means our reference is a moving target; if 2.0.0 GA changes the JS contract, our copied logic is silently stale.
• New — false-positive health signal. Stakeholders see "2.0.0" and read "actively maintained." Correct this explicitly: one RC with an empty changelog is not a maintenance guarantee.
• Abandoned-code drift — still applies; no upstream signal means no one notices a break.

Ramp-up. Unchanged — low for a mid-level Laravel engineer; the concept is intuitive and the code volume is small. The non-obvious learning is regulatory and CMP-specific: which scripts map to which consent category, and what the CMP's own blocking already covers. Assign that mapping to whoever owns privacy/compliance, not to the implementing engineer alone.

TPM verdict. Opportunity score 2.94 against an overall 0.105. The 2.0.0-rc is a signal to verify, not a reason to move. It challenges the "archived and abandoned" finding — the one input that could plausibly have shifted — but it supplies zero evidence of fitness: no changelog, no compatibility statement, no dependents, no maintainer commitment. The two findings that drive the decision (Symfony ≠ Laravel; compliance failure is silent and severe) are untouched by any version number.

Frame to stakeholders as: "Upstream published a major-version release candidate after dormancy. We cannot tell what changed — the changelog is empty. This does not make the package Laravel-compatible. Validate our CMP's native blocking first; if insufficient, fund a small internal build." Add the ~30-minute 2.0.0-rc verification to discovery and timebox the decision there. Do not let a version number reset a decision that was already correct.