Client Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for client identification / attribution. setono/client-bundle is a small, single-purpose Symfony bundle that persists a client identifier in a cookie and exposes extension points around that write. It directly answers "do we hand-roll our own visitor-ID cookie and consent gate, or take a maintained dependency?" — most teams should not be maintaining this themselves.
• Consent-gated tracking (GDPR / ePrivacy / CCPA). The PreStoreCookieEvent is the product-relevant surface: it lets you defer or veto the cookie write until a CMP has recorded consent. This is a compliance feature, not just a technical hook, and it should be represented in privacy/legal reviews as a supported control rather than a custom patch.
• Roadmap input for marketing attribution. Because the bundle only owns the identifier (not the analytics pipeline), it is a building block for referral/affiliate attribution, session stitching, A/B bucketing, and "first-touch vs. last-touch" experiments. Treat it as the identity layer under those features, not as the analytics product.
• Dependency risk and lifecycle planning. This release is a pure engineering-health signal — static analysis at PHPStan level: max, pinned quality tooling, and mutation testing at 100% MSI. That materially lowers the "will this rot / will a silent regression bite us" risk that normally argues against small OSS dependencies, and it is the kind of evidence to cite in a build-vs-buy or vendor-risk memo.
• Upgrade/no-upgrade decisions this cycle. No API or runtime change means the decision is scheduling hygiene, not feature planning: it can ride along with the next routine dependency bump and requires no regression testing beyond the standard suite.
• What it does not decide. It is not a consent-management platform, not an analytics/warehouse layer, and not server-side tracking. Don't let it get scoped into those roadmap conversations.

When to Consider This Package

Adopt when most of the following hold:

• The application is Symfony-based (this is a Symfony bundle, not a Laravel package — Laravel shops would be paying an integration tax for a service provider/event bridge, which changes the calculus considerably).
• You need a stable, first-party client identifier persisted across requests for attribution, personalisation, or experiment assignment, and you'd otherwise write and maintain that cookie logic in-house.
• Consent enforcement is a requirement, and you want a first-class hook (PreStoreCookieEvent) to integrate your existing CMP rather than bolting consent checks onto ad-hoc cookie writes.
• You are on PHP 8.1+ and are comfortable pinning an OSS dependency with active maintenance and strong quality signals.
• You only need the identifier — the surrounding analytics, reporting, and activation live in your own stack.

Look elsewhere when:

• You are on Laravel and want a native package; bridging a Symfony bundle's event dispatcher and container config into Laravel is ongoing cost for a small amount of functionality, and a ~100-line first-party implementation is likely cheaper to own.
• You need a turnkey consent UI / consent record store — that's a CMP (OneTrust, Cookiebot, Usercentrics, or an open-source equivalent), not this bundle.
• You need server-side tagging, a tag manager, or warehouse-grade event collection — this package is deliberately not that.
• You require a commercial SLA, indemnity, or vendor support contract; this is community OSS.
• Your platform is mid-migration away from Symfony, in which case the bundle is a stranded asset.

How to Pitch It (Stakeholders)

For executives: This is a small, actively maintained open-source component that gives us a reliable way to recognise returning visitors and attribute traffic, with a built-in hook so nothing is written to the user's device before consent is captured. The newly published v1.2.0 is a maintenance release — no new features, no API changes, no behavioural changes — so there is no user-facing impact and no product decision attached to it. What it does tell us is that the maintainer invested in static analysis, mutation testing, and rewritten documentation, which is exactly the evidence we want when we choose to depend on a small project instead of building and maintaining the equivalent ourselves. Our recommendation is to take the upgrade as a routine dependency bump and keep the build-vs-buy position unchanged.

For engineering: Drop-in upgrade from v1.1.0 — the changelog explicitly states no public API or runtime changes. Quality bar has gone up (Psalm replaced by PHPStan at max level, tooling unpinned from the setono/code-quality-pack meta-package and individually pinned, Infection added at 100% MSI, PHP 8.1 support retained). Expect the usual lockfile/tooling churn rather than functional risk. The rewritten README now documents requirements, install, the PreStoreCookieEvent consent path, and extension points, which meaningfully lowers onboarding cost for whoever owns this next.

Caveats to state plainly: this is a Symfony bundle, so the "Laravel package" framing overstates its fit for a Laravel codebase — confirm the runtime before we treat it as a candidate. And because v1.2.0 changes nothing functionally, it should not be used as justification for expanding scope into analytics or consent-management territory.