Image Bundle Laravel Package

Technical Evaluation

Architecture fit

• The package sits in the Laravel ecosystem but tracks Symfony component versions, so its support matrix is effectively governed by the Laravel↔Symfony pairing. Requiring Symfony 6 aligns it with Laravel 9+ and removes the legacy Symfony 4/5 code paths, which is the right direction for a package that wants to stay compatible with current framework releases.
• Adopting PHP 8.1 types (union types, readonly, enums, never, first-class callables) tightens the public API contract. That is a net positive for static analysis and IDE support, but it converts previously loose signatures into enforceable ones, which is where the BC risk concentrates.

Integration feasibility

• Straightforward for any application already on PHP 8.1+ and Laravel 9/10 with Symfony 6 components. In that environment 6.0 is a drop-in with a composer constraint bump.
• Not feasible for Laravel 8 estates, PHP 8.0 runtimes, or any dependency graph that still pins Symfony 4/5. Those consumers are frozen on the 5.x line and must either upgrade the whole stack or accept no further updates.

Technical risk

• The [BC] note is the material risk: added parameter/return types and 8.1 language features can break subclasses, interface implementations, decorators, and any consumer that extends or mocks package classes. Signature narrowing (never, union types replacing docblocks) surfaces as fatal errors at load time and TypeError at runtime, not as deprecations.
• Transitive conflict risk is high in the short term: a single third-party dependency requiring symfony/*:^4.4|^5.4 will block adoption and force dependency-graph surgery.
• The PHP 8.1 floor is now past end-of-life, so the package's minimum supported runtime is itself an operational liability. Expect a follow-on major to raise the floor to 8.2/8.3; plan for that cadence.

Key questions

• Which specific 8.1 features were adopted, and is there a written BC/upgrade guide enumerating signature changes?
• Are Symfony constraints ^6.0 only, or ^5.4|^6.0? The release note says "allow Symfony 6" and "drop Symfony 4," which leaves Symfony 5.4 ambiguous.
• What is the minimum supported Laravel version, and is that documented and tested in CI?
• Is the 5.x branch receiving security fixes, and for how long? Is there a published EOL policy?
• Are Rector rules or an automated upgrade path provided for the BC changes?

Integration Approach

Stack fit

• Target profile: PHP 8.1+, Laravel 9/10, Symfony 6 components, Composer 2. Any environment matching this is a clean fit.
• Anti-profile: Laravel 8, PHP 8.0, or anything transitively pinned to Symfony 4/5. Do not attempt partial adoption.

Migration path

1. Inventory: composer why-not <package> 6.0 across all first-party services to enumerate blockers before committing to a timeline.
2. Runtime first: move CI and production images to PHP 8.1+ independently of the package bump, so runtime and library changes fail separately.
3. Framework second: upgrade Laravel/Symfony constraints and confirm the app is green on the existing 5.x package version.
4. Package third: bump to 6.0 on a branch, run static analysis (PHPStan/Psalm at the project's baseline) and the full test suite to surface signature mismatches.
5. Remediate: fix subclass/signature breaks, then merge and deploy behind normal release gates.

Compatibility

• Verify the exact Symfony constraint before planning; if 5.4 remains allowed, the migration window is wider than the note implies.
• Confirm no first-party code extends package classes rather than composing them — extension points are where the BC break bites.
• Check mocking libraries and test doubles; typed signatures can invalidate existing mocks.

Sequencing

• Treat this as a platform upgrade, not a library bump. Do not interleave it with unrelated dependency upgrades; isolate the failure domain so a composer conflict is unambiguous.
• Roll out to the least critical service first to validate the upgrade guide, then batch the remainder once the pattern is proven.

Operational Impact

Maintenance

• Fewer supported branches and a typed codebase reduce maintenance overhead for the package owner and lower the cost of static analysis in consuming repos.
• The 8.1 floor will need to move again; budget for a recurring major-version cadence rather than a one-off upgrade.

Support

• Users unable to upgrade will raise "no fix available" tickets against 5.x. Publish an explicit support window and security-fix policy to preempt this.
• Expect upgrade-assistance requests around the BC changes; an upgrade guide plus Rector rules converts much of that into self-service.

Scaling

• No meaningful runtime performance delta. The value is developer-facing: stricter types improve refactor safety and CI signal as the codebase and team grow.
• Static analysis and IDE tooling on PHP 8.1+ scale better across large monorepos, which matters more than throughput.

Failure modes

• Composer resolution deadlock from a transitive Symfony 4/5 constraint — detected at install, cheap to diagnose with why-not.
• Fatal TypeError / signature-incompatibility errors at class load in subclasses or decorators — detectable only by test coverage, so coverage gaps are the real exposure.
• Silent drift where a service pins ^5.0|^6.0 and unknowingly runs two different majors across environments — enforce a single resolved version in CI.
• Runtime EOL exposure: PHP 8.1 no longer receives security patches, so the package's supported floor inherits that risk.

Ramp-up

• Low for teams already on PHP 8.1/Laravel 9+: an afternoon of constraint work and a test run.
• Medium for teams needing a runtime upgrade concurrently: the effort is dominated by the PHP/framework move, not by this package. Estimate from the runtime upgrade, then add a small allowance for signature fixes.
• Recommend a short internal spike on one service to calibrate before committing to a fleet-wide schedule.