stefpe/sp-consent-bundle
Symfony bundle for handling user consent: define consent types, collect and store opt-ins, and check granted permissions in templates or services. Helps implement GDPR-friendly cookie and privacy consent flows with configurable storage.
This is the first assessment for this package, so start by establishing the version matrix rather than the API surface. The 0.2.0 release is a compatibility release ("Symfony 8 compatibility"), which is the single most important fact about it right now: it tells you the package's Composer constraints were widened (or moved) to admit symfony/* v8 components, and that is either your green light or your blocker.
Do these three things in order:
composer show <vendor>/<package> --all and look at the requires block. The relevant question is whether 0.2.0 declares ^7.0|^8.0 (dual support — safe to adopt broadly) or ^8.0 only (Laravel 13+ / PHP 8.4+ territory). Symfony 8 requires PHP 8.4, so an ^8.0-only constraint silently raises your application's minimum PHP version.composer show symfony/http-foundation | grep versions. If your Laravel install is still resolving Symfony 7.x, a dual-support package will install fine and you get no benefit yet; an ^8.0-only package will refuse to install. Knowing which case you are in shapes everything below.composer require <vendor>/<package>:^0.2 --with-all-dependencies. The --with-all-dependencies flag matters here because widening a Symfony constraint can trigger upgrades of transitive packages you did not intend to move.Where to look first, in priority order: the package's composer.json (constraints reveal more than the release note), then the service provider (src/*ServiceProvider.php) to see whether anything is auto-registered or publishable, then the README for the documented entry point. For a 0.x package the README is frequently ahead of or behind the code — treat the provider and the tests as the source of truth.
The first use case worth validating is the thinnest possible end-to-end path: register the provider (if manual), resolve the package's main entry point out of the container, and exercise one call. If that works on both Symfony 7 and Symfony 8 in your CI, you have established the only thing 0.2.0 actually claims.
Pin the minor, range the patch. For a pre-1.0 package, use "<vendor>/<package>": "~0.2.0" rather than ^0.2. A 0.3.0 may carry breaking changes; a 0.2.4 should not. The Symfony 8 work landed in 0.2.0 specifically, so anything below it is a different compatibility story — do not assume 0.1.x will resolve on a Symfony 8 stack.
Build a two-cell CI matrix. This is the highest-value pattern for a package whose headline feature is cross-version support. One job on your current Laravel/PHP combination (Symfony 7), one on PHP 8.4 with symfony/*:^8.0 allowed. Run the same test suite against both. Cross-version claims in 0.x packages are frequently asserted by constraint change and verified only on one leg; your matrix catches the gap before production does.
Constrain the transitive graph, not just the package. If the package is a bridge or adapter, add explicit symfony/* constraints in your root composer.json for the components you actually touch. Without this, composer update can promote Symfony 8 into your application on a routine dependency refresh, months after you evaluated 0.2.0, with no signal. Root-level constraints are your seatbelt against a transitive widening.
Wrap the package behind your own interface. At 0.x this is worth the small cost. A thin adapter class in your app/ namespace means an upgrade that breaks the package's signatures — or a switch to a different package entirely — is a one-file change rather than a grep across the codebase. Bind the adapter in a service provider and inject the interface; never let framework-adjacent third-party types leak into your domain layer.
Exercise it through the application container. Resolve the package via app() or constructor injection in tests rather than instantiating it directly, so the service provider's bindings and any config merge are part of what you are testing. Configuration-driven behaviour is where cross-version differences tend to surface.
Test the failure path on the version you are not running. If you ship on Symfony 7, write at least one test that asserts the package's documented behaviour when a Symfony 8-only code path is not taken. Compatibility releases change branch selection inside the package; the untaken branch is the one nobody tested.
Pre-1.0 semver gives you nothing. Under semver, 0.x minors are permitted to break. Treat 0.1.x → 0.2.0 as a potentially breaking upgrade regardless of the bland release note. Read the diff, not the summary — "Symfony 8 compatibility" often disguises removed shims and changed method signatures.
A compatibility release is a constraint change first and a code change second. If the package only widened constraints without exercising Symfony 8 in CI, the compatibility is theoretical. Check whether the release tag has a corresponding CI matrix change; if not, assume you are the first person running it on Symfony 8 and budget debugging time accordingly.
PHP 8.4 is the real gate. Symfony 8 components require PHP 8.4. If your deployment image, your local toolchain, or a CI runner is on 8.3, an ^8.0-only constraint fails at install time with a confusing platform error. Verify php -v across every environment before blaming the package.
Debug resolution with why-not, not with guesswork. When install fails, composer why-not symfony/http-foundation 8.0 names the exact package holding the version back. composer show --tree shows you the graph. composer update --with-all-dependencies --dry-run previews the blast radius before you commit to it. These three commands resolve nearly every constraint conflict faster than reading error prose.
Do not mix Symfony major versions across the graph. Composer will usually prevent this, but --ignore-platform-reqs or a stale lockfile can produce a tree with Symfony 7 and Symfony 8 components side by side. Symptoms are bizarre: type errors on interfaces that "obviously" match, or silent behaviour changes in HTTP handling. If you see that class of bug, run composer show | grep symfony/ and confirm every component shares a major.
Deprecation removal is the likely break, not new API. Symfony majors remove what previous minors deprecated. If the package was quiet through Symfony 7's deprecation cycle, 0.2.0's "compatibility" work was likely fixing those call sites — which means behaviour can shift subtly even where signatures did not. Run your test suite with deprecation reporting on, on both legs of the matrix.
Watch the lockfile across teams. Adding a dual-constraint package lets two developers resolve different Symfony majors from the same composer.json. Commit the lockfile, and if the package is genuinely optional, consider whether both majors need to be supported in one branch at all versus pinning per environment.
Extension points are your escape hatch. Before you adopt, identify how the package lets you override behaviour — published config, bound interfaces, or an event/hook system. A 0.x package that hard-codes its dependencies and exposes no override surface is a liability on a Symfony major boundary; one with a config file and interface bindings lets you patch around a gap without forking. Note which it is now, while you are reading the provider anyway.
Defer the upgrade if you are not on Symfony 8. If your stack is Symfony 7 and stable, 0.2.0 buys you nothing today beyond constraint drift risk. The value is optionality for the eventual Symfony 8 migration — so track it, pin the current working version, and adopt 0.2.x when you begin the framework upgrade, with the matrix already in place to tell you whether it holds.
How can I help you explore Laravel packages today?