Dadata Bundle Laravel Package

Technical Evaluation

Architecture fit

• The package is a Laravel/PHP library; v1.6.0 adds Symfony 7 support. Because Laravel 11 is built on Symfony 7 components, this release is the strongest available signal that the package is intended to remain viable on the current Laravel major line.
• Fit for our stack is probable but unverified: we have no repository metadata, composer constraints, service-provider surface, or test matrix for this package. The only confirmed fact is Symfony 7 compatibility.
• Symfony 7 imposes a PHP 8.2 floor. If our applications still run PHP 8.1, this release is not adoptable regardless of Laravel version.

Integration feasibility

• Likely low-effort for greenfield Laravel 11 services: standard Composer install, optional service provider auto-discovery, config publish step.
• Feasibility is materially lower for existing Laravel 9/10 services, which resolve Symfony 6.x. A package that has moved its constraints to Symfony 7 may no longer co-install with those applications.
• The release is a minor version bump, which conventionally implies backward compatibility, but dependency-range changes can break Composer resolution without any API change. Treat "minor" as an API promise, not a dependency promise.

Technical risk

• Dependency-resolution risk (highest): if v1.6.0 widens to ^6.4|^7.0 the risk is low; if it narrows to ^7.0 only, it silently strands every Laravel 9/10 consumer. This must be confirmed from composer.json, not inferred from release notes.
• PHP floor risk: Symfony 7 requires PHP ≥ 8.2, which may raise the package's own php constraint and break CI on older runners.
• Transitive conflict risk: Symfony components are heavily shared; a forced Symfony 7 pin can collide with packages still on Symfony 6.
• Documentation/translation risk: release notes are in Russian only. Minor, but it signals a single-maintainer project where changelog detail may be thin — reducing our ability to assess changes without reading diffs.

Key questions

1. What are the exact composer.json constraints for php, illuminate/*, and symfony/* in v1.6.0 versus v1.5.x?
2. Did v1.6.0 add Symfony 7 alongside Symfony 6.4, or replace it? (Determines whether Laravel 10 remains supported.)
3. Is there a published Laravel/Symfony/PHP support matrix, and is it CI-enforced?
4. Are there any deprecations, removals, or behavioral changes bundled into this release beyond the Symfony constraint change?
5. Who maintains the package, what is the release cadence, and is there a security disclosure channel?

Integration Approach

Stack fit

• Target: Laravel 11 (Symfony 7 components), PHP 8.2+. This release aligns the package with that target.
• Laravel 10 (Symfony 6.4) and Laravel 9 (Symfony 6.0–6.2) compatibility is undetermined and must be confirmed before we treat the package as usable across our estate.

Migration path

1. Read composer.json at the v1.6.0 tag and diff the constraint block against v1.5.x.
2. Run composer why-not <package> 1.6.0 in a representative Laravel 10 app and a representative Laravel 11 app. Two commands, definitive answer.
3. If Laravel 10 resolves cleanly, schedule a normal minor upgrade. If it does not, treat v1.6.0 as a Laravel-11-only line and plan application upgrades first.
4. Pin the resolved version in composer.lock and commit; do not float the constraint until the support matrix is confirmed.

Compatibility

• Confirmed: Symfony 7.
• Unconfirmed: Laravel majors, PHP floor, database/driver support, other framework bridges (e.g. Lumen, Octane, Nova).
• Practical rule: adopt only on Laravel 11 / PHP 8.2+ services until proven otherwise.

Sequencing

1. Constraint audit and why-not check (same day, no code change).
2. Pilot on one non-critical Laravel 11 service; run the existing test suite plus a smoke test of the package's primary feature path.
3. Extend to remaining Laravel 11 services.
4. Defer Laravel 9/10 services until either the package proves dual-Symfony support or those applications are upgraded.

Operational Impact

Maintenance

• The package is now tracking a current Symfony major, which is a positive maintenance signal: it means the maintainer is reacting to upstream releases rather than drifting.
• Counter-signal: a single-line changelog for a dependency-major change suggests limited release documentation. Budget for reading diffs on future upgrades rather than relying on notes.
• Recommend a standing quarterly review of the package's supported Laravel/Symfony window; if it lags Symfony 8, we inherit the same decision again.

Support

• Vendor/support model unknown (single maintainer vs. organization). Escalation path is unverified.
• Because release notes are non-English, internal support documentation should include our own English summary of each upgrade.
• Mitigation if the package is load-bearing: fork-and-patch capability, or an abstraction layer at the call site so the dependency is replaceable.

Scaling

• Symfony 7 alignment has no meaningful runtime scaling implications; it is a compatibility change, not a performance one.
• The scaling concern is organizational: one package version now gates which Laravel majors we can run, which can fragment the fleet into "Laravel 11 + v1.6" and "Laravel 10 + v1.5" cohorts with separate patch streams.

Failure modes

• Silent install failure: Composer refuses to resolve on Laravel 9/10 apps — visible and safe, fails at build time.
• Silent behavioral drift: if Symfony 7 support changed internal component usage, behavior may differ subtly between Symfony 6 and 7 code paths (e.g. HTTP kernel, event dispatcher, console). Highest-risk failure, invisible to Composer, caught only by tests.
• CI gap: if the package's own CI does not test Symfony 6 anymore, dual-support claims are unverified for our Laravel 10 apps.
• Stranding: if v1.5.x stops receiving security patches once v1.6.x is out, Laravel 9/10 services become an unpatched liability.

Ramp-up

• Engineering: minimal — roughly half a day for the constraint audit plus one pilot service; no new conceptual model for the team.
• TPM: one decision to record — "v1.6.0 defines our supported baseline as Laravel 11 / PHP 8.2+ until proven otherwise," with an owner and a review date.
• Documentation: capture the confirmed support matrix in our internal package register, and note that the assessment is based on release notes alone — the constraint diff is a prerequisite to any adoption decision.