Consent Bundle Laravel Package

Technical Evaluation

Architecture fit

• setono/consent-bundle is a Symfony bundle, not a Laravel package. Its value proposition is split in two: (a) setono/consent-contracts — a framework-agnostic PHP abstraction for asking "has this visitor consented to X?"; and (b) the bundle — Symfony DI extension, configuration tree, service definitions, event subscribers, and Twig helpers that wire those contracts into a Symfony kernel. Layer (a) is portable; layer (b) is not. Laravel has no Bundle::boot() equivalent and will not load *Bundle classes.
• Realistic architecture fit for a Laravel codebase is therefore the contracts as a dependency, wrapped in our own service provider — not the bundle. Any assessment that assumes composer require setono/consent-bundle "just works" in Laravel is wrong.
• The v1.2.0 release ("set the default consent checker in the configuration of the bundle") lands entirely in layer (b). It is a config-tree convenience for Symfony DI: a default_consent_checker-style key that selects which checker implementation is injected when none is specified. It does not add contract surface, does not change the interface shapes in setono/consent-contracts, and does not make the bundle loadable in Laravel. Net effect on architecture fit: none.
• The abstraction itself (typed consent categories, a consent-checker interface, decoupled from cookie/session/storage mechanics) remains the genuinely valuable idea and is worth adopting even if we never ship the dependency.

Integration feasibility

• Low-to-moderate, unchanged by v1.2.0. Installing the contracts package alone is likely trivial; the work is in the adapter layer: binding the contract interfaces into Laravel's container, replacing Symfony's event dispatcher with Laravel events/middleware, and replacing Twig helpers with Blade directives or a @consent directive.
• v1.2.0 does give one genuine integration insight: upstream now treats "which default checker wins" as a first-class, configurable concern. That question is equally live in our port — our ConsentServiceProvider must explicitly bind a default implementation rather than letting container resolution fail open. We get the same capability for free in Laravel config and should model it deliberately (config/consent.php → default_checker).
• One favorable accident: Laravel's Illuminate\Http\Request extends Symfony\Component\HttpFoundation\Request, and symfony/http-foundation is already a transitive Laravel dependency. If the bundle's consent resolution touches only HttpFoundation, the porting surface shrinks. It will not help with symfony/dependency-injection or framework-bundle — both of which the v1.2.0 feature is built on.
• Budget a 1–2 day spike to answer whether the contracts package installs and functions with zero Symfony kernel assumptions. That spike is the go/no-go gate, and v1.2.0 does not shorten it.

Technical risk

• Adoption signal is the dominant risk: 4 stars, 0 dependents, score 0.02. This is effectively a single-maintainer, pre-critical-mass package. The v1.2.0 drop (following v1.1.0 and the 2025-01-13 release) is a positive maintenance-cadence signal — two releases in short succession suggests an active maintainer — but does not offset the bus factor or the dependent count.
• Symfony major-version coupling (5/6/7 constraints, PHP version pins) can create composer conflicts with Laravel's own Symfony component versions — a classic transitive-constraint trap. Not touched by v1.2.0.
• Legal exposure is asymmetric: a consent library that silently fails open is worse than no library. v1.2.0 makes the default checker a configuration decision, which is exactly where fail-open regressions hide. We must verify default-deny behavior ourselves rather than trusting the abstraction or its defaults.

Key questions

1. Does the bundle require a Symfony kernel/DI container at runtime, or is the contracts package usable standalone?
2. Where is consent state persisted — cookie, session, DB? Is there an audit trail (timestamp, policy version, subject identifier) sufficient for GDPR/ePrivacy evidence?
3. Does it enforce blocking of tags/scripts, or only expose a query API? Blocking is the part that actually carries compliance weight.
4. Is consent versioned against policy text, so a policy change triggers re-consent?
5. What are the exact composer.json constraints, and do they collide with our Laravel/Symfony component pins?
6. Is there jurisdiction awareness (EU opt-in vs. US opt-out), or is it one-size-fits-all?
7. (new) What is the shipped default value of the default consent checker in v1.2.0 — deny-by-default or grant-by-default? Does changing it require a container rebuild, and is the default documented? This tells us whether upstream's out-of-box posture is fail-closed.

Integration Approach

Stack fit

• Target: Laravel 10/11/12, PHP 8.1+. Treat setono/consent-contracts as a dev-time reference and optional dependency, and treat the bundle as not installable — v1.2.0 does not change this.
• Recommended shape: our own ConsentServiceProvider exposing a ConsentManager singleton behind a facade, implementing the contracts' interfaces. Blade directive (@whenConsented('analytics')) for template gating; middleware (EnsureConsent:analytics) for route-level gating.
• Mirror v1.2.0's configurability in our own layer: config/consent.php with a default checker key bound in the service provider, so the "which checker wins" decision is explicit, reviewable in a PR, and testable — rather than an implicit container fallback.
• Keep the vendor abstraction at the boundary so a later swap to a JS-side CMP (OneTrust, Cookiebot, Osano) with server-side verification is a single-class change.

Migration path

1. Spike (1–2 days): install contracts in a scratch Laravel app, implement one adapter, confirm no Symfony container dependency. Record result as an ADR.
2. Abstraction first: define our ConsentManager interface and default-deny implementation before wiring any analytics. This decouples us from the package decision.
3. Gate the tags: route all GA4/Meta/pixel injection through the consent gate; where possible pair with Google Consent Mode v2 so client-side tags degrade correctly.
4. Persist evidence: add a consent_records table (subject, category, granted/denied, policy version, timestamp, IP/UA hash) — this is ours to own regardless of package.
5. Re-evaluate: at ~90 days, decide whether the contracts dependency earned its place or should be replaced by ~200 lines of in-house code. Fold the v1.2.0 changelog into this review so cadence is assessed against a trend line, not a single release.

Compatibility

• Verify symfony/http-foundation version alignment with Laravel's pinned range before committing; a mismatch here forces a fork or a version downgrade we won't accept.
• If a fork is needed, MIT licensing permits it — budget for a setono/consent-contracts fork under our org with a documented divergence policy. Note that v1.2.0's feature is bundle-only, so a contracts-only fork stays small.
• If we ever do pull the bundle in (we should not), v1.2.0 is a minor, non-breaking config addition — no migration cost, but also no change to the Symfony-kernel requirement that blocks us.

Sequencing

• Do not block the compliance workstream on this package. The blocking/middleware/audit-table work is package-independent and should start immediately; the contracts adoption is an optimization layered on top.
• v1.2.0 introduces no urgency: nothing in it is on our critical path, and nothing in it shortens the spike. Do not re-sequence work for it.

Operational Impact

Maintenance

• Assume no upstream maintenance guarantee. With 0 dependents and 4 stars, we are likely the largest consumer. Plan for a fork-or-vendor fallback and assign a named in-house owner.
• Two releases inside a short window (v1.1.0, v1.2.0, on top of the 2025-01-13 release) is the best signal we have that the maintainer is engaged. It does not change the fallback plan, but it does move the 90-day re-evaluation from "likely abandon" toward "monitor."
• Low churn expected (consent abstractions are stable), so maintenance cost is mostly review cost, not fix cost — a few hours per quarter. v1.2.0 is a good calibration point: a functional release that required zero action from a contracts-only consumer.

Support

• Community-only, no SLA, no commercial backing. Escalation path is "read the source," which is acceptable for a small library and unacceptable for anything on the critical compliance path. This argues again for wrapping it rather than depending on it directly.
• v1.2.0's changelog is a single sentence plus an auto-generated compare link — no rationale, no default-value documentation, no upgrade notes. Treat that as representative of the support experience and price it into the spike.

Scaling

• Consent checks sit on every request and every tag render. Resolve the consent decision once per request as a scoped singleton; never re-read cookies in loops.
• With a configurable default checker (v1.2.0's model), ensure the default is resolved at container/config build time, not per request — a per-request default lookup is an avoidable hot-path cost.
• Client-side is the real scaling surface: consent gating must be enforced at the tag manager/CDN edge too, or server-side gating becomes theater.
• Storage growth is linear and trivial; the audit table should be partitioned or archived on a retention schedule.

Failure modes

• Fail-open regression: a misconfigured adapter defaults to "granted," silently shipping data. v1.2.0 makes the default checker explicitly swappable, which raises this risk if the shipped default is permissive or if an operator overrides it without review. Mitigate with default-deny plus an integration test asserting denial with no cookie, and a config test asserting our default key is the deny checker.
• Middleware ordering: consent middleware registered after a tracking middleware is a no-op. Enforce ordering in a test.
• Stale consent: policy text changes without a version bump means users never re-consent. Own the version field ourselves.
• Composer conflict at upgrade time: a Laravel major upgrade forces a Symfony component bump and the dependency becomes uninstallable mid-sprint.
• Abandonment: upstream goes dormant; we discover it during an incident. Currently lower probability than at last assessment.

Ramp-up

• 2–3 days for a mid-level engineer to read the contracts, implement the adapter, and write the denial-path tests. Documentation is likely thin, so budget for source reading.
• TPM-level ramp is a half-day: read the contracts' interfaces, read the ADR, understand that the bundle is not the artifact we consume. The primary TPM deliverable here is the decision record explaining why we adopt the contracts and not the bundle, plus the 90-day re-evaluation checkpoint.
• Delta from v1.2.0: none for ramp-up. The release adds a bundle configuration key we will not consume; no new concepts, no new interfaces, no new reading. Record it in the ADR changelog as "reviewed, no action."