Client Bundle Laravel Package

Technical Evaluation

Architecture fit. setono/client-bundle is a Symfony bundle, not a Laravel package: it ships a bundle class registered through config/bundles.php, DI extension/service configuration, and a PreStoreCookieEvent consent hook. Our prompt frames this as a Laravel/PHP evaluation, so the honest assessment is that architectural fit is conditional: strong if the target application is Symfony (or a Symfony-based commerce stack such as Sylius/Shopware-adjacent), and non-trivial for a Laravel codebase, where we would either (a) pull in the underlying framework-agnostic client libraries and skip the bundle, or (b) build a thin Laravel service provider bridge. The bundle's value-add over the raw client is configuration, event wiring, and consent gating — the parts most tightly coupled to Symfony's event dispatcher.

Integration feasibility. v1.2.0 is explicitly a maintenance/tooling release with no public API or runtime changes, so it is a drop-in upgrade from v1.1.0. Composer-level work is confined to require-dev (Psalm → PHPStan at level: max, replacement of the setono/code-quality-pack meta-package with individually pinned tools, Rector 2, ECS, composer-dependency-analyser, Infection). PHP 8.1 support is retained. Nothing here changes the consuming application's composer constraints, service definitions, or event contracts.

Technical risk. Upgrade risk: low. Adoption risk: moderate, driven by (1) framework mismatch if the destination is Laravel, (2) the consent path being the only real correctness surface — a misconfigured or un-dispatched PreStoreCookieEvent can silently suppress or prematurely allow cookie storage, which is a compliance issue rather than an availability one, and (3) bus-factor and release cadence on a small third-party bundle. The tooling signals are genuinely positive for a dependency of this kind: PHPStan at max level plus 100% MSI mutation testing materially raises confidence that future patch/minor releases are behaviour-preserving, which is exactly the property you want from a third-party integration point.

Key questions.

• Is our target application Symfony or Laravel? If Laravel, is a bridge provider in scope, or do we consume the underlying client directly?
• Which consent/CMP integration does PreStoreCookieEvent bind to, and does it map onto our CMP (or Laravel's cookie encryption/consent middleware)?
• What are the transitive runtime dependencies (Symfony version range, PSR interfaces) and do they collide with our framework constraints?
• What is the maintainer's BC/versioning policy post-1.0, and what is the supported PHP/Symfony window?
• Does the "100% MSI" claim cover integration paths (bundle boot, event dispatch) or unit-level logic only?
• Who owns upgrades internally, and is there a fallback if the bundle is abandoned?

Integration Approach

Stack fit. Confirm framework first. On Symfony, this is a conventional bundle with a Flex recipe path documented in the rewritten README, so fit is high and the integration is declarative. On Laravel, the bundle is the wrong abstraction layer; the viable path is the underlying client plus a custom provider, which shifts effort from configuration to glue code and must be costed before committing.

Migration path. For existing v1.1.0 consumers: composer update setono/client-bundle to ^1.2.0, run the existing test suite, no code or config changes. For new adopters: install via Flex (or manual bundle registration), configure the client credentials, and wire consent handling through PreStoreCookieEvent before enabling anything that writes cookies. The README rewrite makes the manual install path and the extension points legible enough that a first integration no longer depends on reading the source.

Compatibility. PHP 8.1 floor is unchanged, so no runtime upgrade is forced. The dev-tooling swaps are invisible to consumers — Psalm/PHPStan, Rector 2, ECS, and Infection live in require-dev and are not installed in production. The one thing to watch is composer-dependency-analyser: tightening of declared dependency constraints in this release or the next can surface previously-masked version conflicts in our lockfile, so pin and test rather than float.

Sequencing.

1. Upgrade a non-production environment to ^1.2.0, run the full suite, diff the lockfile for transitive changes.
2. Exercise the consent flow end-to-end: verify PreStoreCookieEvent fires and that no cookies are written pre-consent.
3. If Laravel, run a short spike on the bridge/raw-client option before upgrading — the answer may change the integration design entirely.
4. Pin the version and record the PHP/Symfony support window we are relying on.
5. Promote to production; no rollout coordination required given the absence of runtime change.

Operational Impact

Maintenance. Low steady-state cost on Symfony: no runtime footprint from the tooling change, and the drop-in nature means upgrades are cheap. Real maintenance effort is periodic dependency hygiene (Symfony range, PSR packages) rather than code changes. Budget a small recurring allocation to track upstream releases, because the value of this package is precisely that it stays current with the framework.

Support. The README rewrite is the headline operational improvement: requirements table, install paths, consent handling, "How it works", extension points, and a contributing guide substantially reduce the cost of the first integration and of onboarding a second engineer. Offsetting that, this remains a small-team, third-party dependency with no commercial support — we should assume self-support and keep our integration surface thin.

Scaling. No runtime change in v1.2.0, so no performance delta and no new scaling considerations. The scaling characteristics that matter are those of the underlying client and the consent mechanism: cookie volume per visitor, any server-side dispatch or queueing, and whether the client call is synchronous in the request path. None of these are altered here.

Failure modes.

• Consent misconfiguration — the highest-severity failure. A missing or misordered PreStoreCookieEvent listener either blocks legitimate storage or permits storage before consent. Neither throws; both are silent. Requires an explicit test, not just a smoke check.
• Dependency conflict — a Symfony/PSR version range tightening colliding with our stack, surfacing only at composer update.
• Abandonment or stalled maintenance — mitigated somewhat by the modern tooling baseline (a maintainer investing in PHPStan max and mutation testing is signalling intent to continue), but not eliminated.
• Framework-mismatch drift — if we adopt via a Laravel bridge, upstream Symfony-specific changes can break our glue code even when the public API is stable.

Ramp-up. For a Symfony team: hours. The concept count is small (one bundle, one event, one config block) and the new README covers the extension points. For a Laravel team: days, dominated by the bridge decision and by re-implementing the consent wiring outside Symfony's dispatcher — and that is the point at which a TPM should question whether the bundle, rather than the underlying client, is the right dependency.