Dadata Bundle Laravel Package

Getting Started

This release (v1.6.0) is a compatibility release: the headline change is Symfony 7 support. For a Laravel developer the practical meaning is narrow but important — Laravel 11 ships on Symfony 7 components, so if you previously hit a composer conflict pinning this package to symfony/* ^6, that wall is now gone.

Minimal steps:

1. Check what you are actually running before changing anything:

   php -v                      # Symfony 7 requires PHP >= 8.2
   composer show -t | grep symfony
   composer why symfony/console
   

2. Attempt the upgrade in isolation and read the solver output, not just the exit code:

   composer require vendor/package:^1.6 --with-all-dependencies --dry-run
   

3. Clear cached config and container artifacts after the version bump — a stale bootstrap/cache/config.php is the most common cause of "it worked in CI but not locally" after a dependency change:

   php artisan config:clear && php artisan cache:clear
   

4. Where to look first in the package itself: the service provider (what it binds into the container and whether the binding differs by framework), the published config file (defaults are the real API surface), and the composer.json require/conflict block — that last file tells you more about this release than the changelog does.

First use case to validate: the package's primary documented happy path, exercised through Laravel's container rather than constructed manually. If it resolves via app(...) and works with config published, the framework wiring survived the Symfony 7 jump. The Symfony-side integration is irrelevant to your Laravel app unless you are deliberately sharing code between a Laravel and a Symfony application.

Implementation Patterns

Treat the core as framework-agnostic. A package that ships both a Laravel and a Symfony integration almost always has a framework-free core with thin adapters. Resolve the core service from the container and pass configuration explicitly rather than reaching for framework globals — that keeps your code portable and makes the package easier to swap or fake.

Constructor injection over facades. Bind in a service provider and inject into your own classes:

public function __construct(private PackageManager $manager) {}

Facades are convenient in controllers but make the package's framework coupling leak into domain code, which is exactly the coupling this release is trying to loosen.

Configuration as the integration point. Publish the config once and treat it as your application's contract with the package. Environment-specific values belong in config/ reading from env(), not in env() calls scattered through the app. After publishing, diff the shipped defaults against your published copy on every minor bump — additive config keys silently defaulting can change behaviour.

Version constraint strategy. For libraries or shared internal packages depending on this package, widen the constraint rather than bumping the floor:

"vendor/package": "^1.4 || ^1.5 || ^1.6"

This is what actually lets your downstream consumers on Laravel 11 install. Pinning to ^1.6 unblocks you but blocks anyone still on Symfony 6 / Laravel 10.

Test the upgrade, not the feature. Your existing tests are the regression suite here — this is a dependency-compatibility release, so no new behaviour to assert. Add a CI matrix row for the oldest and newest supported framework/PHP combinations rather than testing only the tip. If the package exposes fakes or test helpers, use them; otherwise bind a mock of the injected core service in the container for unit tests and reserve a single integration test for the real binding.

Queue and event paths are the ones that break. Container wiring failures are loud and caught immediately; serialized jobs and event payloads carrying package objects across a version boundary are quiet. If you queue package objects, verify they still serialize and deserialize after the upgrade.

Gotchas and Tips

• PHP floor moves with Symfony 7. Symfony 7 requires PHP 8.2. If any part of your fleet — or a shared CI image — is still on 8.1, this release is not installable there. Confirm before planning the rollout.
• The changelog is one line; read the diff. "Symfony 7 support" can hide a widened constraint (^6.4 || ^7.0, safe) or a dropped one (^7.0 only, a de-facto breaking change for anyone on Symfony 6). Check composer.json in the tag, not the release notes.
• --with-all-dependencies or nothing. Without it, Composer will happily keep a conflicting transitive symfony/* in place and you will debug a phantom failure. Add --dry-run first and read every line of the solver output.
• Transitive Symfony component bumps are the real risk. Adding Symfony 7 support often means relaxing constraints on symfony/console, symfony/http-foundation, symfony/serializer, etc. Those are shared with Laravel core. Run the full test suite, and specifically any snapshot/serialization tests, after the bump.
• Semver says safe, semver is a claim. 1.6.0 promises no breaking changes, but "support" releases sometimes also remove shims for old versions. Scan CHANGELOG/git log between your current version and 1.6.0 rather than reading only the top entry.
• Cache layers. Config cache, route cache, container cache, and any OPcache/preload setup. On a version bump, clear all of them. php artisan optimize:clear covers the Laravel side.
• Extension points to prefer. Prefer the package's documented events, decorators, or interface bindings over class_exists checks and over subclassing concrete classes. The latter are the things that break on minor releases, and a package supporting two frameworks will keep reshuffling its concrete internals.
• Do not mix adapters. If you use the Laravel integration, do not also boot the Symfony bundle in the same app to reach a feature. Two container wirings for one service is a reliable source of duplicated singletons and confusing state.
• Upgrade urgency: low, conditional. If you are on Laravel 10 / Symfony 6 with no install conflicts, there is no forcing function here — take it in your normal dependency cadence. If you are on Laravel 11 and were blocked, this release is the unblock; verify and ship it.
• Watch for the next patch. Compatibility releases like this commonly get a fast follow-up (1.6.1) for a missed constraint in a dev dependency or a PHP 8.2 deprecation. If you are not blocked, one week of soak time is cheap insurance.