Progressive Image Bundle Laravel Package

Technical Evaluation

What this is. Progressive Image Bundle 2.0.0-rc1 is a from-scratch DDD rewrite of the variant generation pipeline, and the first release that no longer depends on LiipImagineBundle. Critically for us: this is a Symfony bundle, not a Laravel package. There is no service provider, no Blade integration, and no Laravel queue transport. Our evaluation therefore splits into two questions — can we consume it, and can we borrow from it.

Architecture fit. The core design is genuinely interesting regardless of framework. Content-addressed variants (each generated size keyed by a deterministic hash of source + spec) means any worker produces the same artifact with no coordination beyond a short-lived lock. That is the correct answer to the classic "N queue workers race to generate the same thumbnail" bug, and it is the single most valuable idea in this release. The three generation strategies (sync, terminate, async via Messenger) map conceptually onto Laravel's synchronous path, dispatchAfterResponse(), and queued jobs respectively — the concepts port, the code does not.

Integration feasibility. Low as a drop-in. High as a reference architecture or a sidecar service. The realistic paths are: (1) stand the bundle up as a separate Symfony service exposing its on-the-fly resolve route, and have Laravel call it over HTTP; (2) reimplement the content-addressed pipeline inside Laravel on top of intervention/image ^4.2, which is a plain PHP library and is the actual reusable asset here; (3) do nothing until 2.0.0 is stable. The Symfony Flex recipe and the pgi_filter() Twig function are explicitly not leverage for us — we would need a Blade directive and a Laravel-side resolver equivalent to ResolveFilterUrlHandler.

Technical risk.

• Pre-release churn. The maintainers state plainly that breaking changes are expected before 2.0.0. Any production use requires pinning the exact version and accepting upgrade work.
• PHP 8.3+ floor. Raised from 8.2 by the intervention/image ^4.2 dependency. This is a hard gate on our fleet and on any Laravel version matrix we support; it must be confirmed before any design work starts.
• Container-level fragility. Two of the three rc fixes are container/wiring bugs (asset_mapper resolver breaking compilation on projects without asset-mapper; Messenger transport not actually routed). That pattern suggests the integration surface is still settling.
• Runtime binary dependency. Real post-processing (jpegoptim, pngquant, cwebp, avifenc) means these binaries must exist in every runtime image. Missing binaries are a silent quality/format regression, not a crash.
• Single-source maturity. Documentation lives at pgi.blue; the migration guide is Liip-to-PGI, which is not our migration.

Key questions for the maintainers / our own spike.

1. Can the Variant pipeline be used standalone, without booting the Symfony bundle — i.e. is there a framework-agnostic core?
2. Where does the content-addressed variant store live, and does it require a shared filesystem or does it support S3-compatible object storage? This determines whether the scaling story survives multi-node.
3. What is the lock implementation and its TTL under lock contention?
4. What is the stability commitment and timeline for 2.0.0 final, and is there a BC policy after that?
5. Does the async strategy have retry/dead-letter semantics we can map onto Laravel's queue?

Integration Approach

Stack fit. Poor out of the box, moderate with deliberate effort. Every advertised integration point is Symfony-native: Twig function, Symfony service, Symfony Messenger transport, Symfony CLI commands, Flex recipe. Our stack's equivalents (Blade, service container bindings, Laravel queues, Artisan commands, package discovery) all require bespoke work. There is no Laravel package, no Laravel documentation, and no community track record in our ecosystem.

Migration path. There is no migration path from our likely incumbents (Intervention Image directly, spatie/image, Glide) — the release's migration guide is for Liip users only. If we are currently on LiipImagineBundle anywhere, this is a clean win; if we are not, we are adopting from zero. Treat this as greenfield, not migration.

Compatibility.

• PHP 8.3+ versus our current floor — the gating constraint.
• Symfony 6.4 / 7.4 / 8.1+ — irrelevant to Laravel but relevant if we take the sidecar route, where we inherit a second framework's upgrade cadence.
• intervention/image ^4.2 — the one dependency we can adopt directly today, independent of the bundle.
• asset_mapper fix confirms the bundle degrades gracefully when Symfony optional packages are absent; no equivalent guarantee exists for Laravel, because Laravel is not a supported target at all.

Sequencing. Recommend a four-step path:

1. Now — adopt intervention/image ^4.2 independently if it fits our PHP floor, and prototype the content-addressed variant key (hash of source + spec) inside a Laravel job. This captures ~70% of the value with none of the pre-release risk.
2. Now — stand up 2.0.0-rc1 as an isolated sidecar service in a non-critical path (staging asset pipeline) to validate the resolve route, the filter set, and the binary post-processing in our container images.
3. At 2.0.0 stable — re-evaluate the sidecar against a native Laravel implementation on cost, latency, and operational surface.
4. Only if the sidecar proves clearly superior — accept the second-framework operating cost, or fund an extraction.

Do not sequence any of this behind the Symfony Flex recipe; it delivers zero value to us.

Operational Impact

Maintenance. Pre-release software with an explicit breaking-change warning. Expect to pin the exact rc and budget upgrade work per rc. Post-2.0.0, the maintenance question becomes: are we maintaining one Laravel image pipeline, or two framework runtimes plus an HTTP boundary? The sidecar route quietly doubles our framework upgrade obligations.

Support. Documentation is solid and centralized at pgi.blue, but entirely Symfony-oriented. Our team will be reading Symfony docs to debug a Laravel integration. There is no vendor support, no SLA, and no evidence of a large maintainer base. Escalation is "read the changelog."

Scaling. This is the release's strongest dimension and the reason it merits evaluation at all. Content addressing makes generation idempotent and worker-agnostic, which is exactly what we need for horizontally scaled queue workers and multi-region CDN origin fill. The async strategy decouples generation from request latency. Caveat: the content-addressed store must be shared across all workers — shared volume or object storage. If variants land on local ephemeral disk per worker, the entire scaling benefit evaporates and we get 404s on cache misses. This must be resolved architecturally before any rollout.

Failure modes to instrument.

• Missing post-processing binaries → silent fallback to unoptimized/wrong-format output. Needs a startup health check, not a runtime surprise.
• Lock contention / lock leak under burst load → generation stalls or duplicate work.
• Async backlog → resolve route serves 404s or placeholder loops for uncached variants. Needs a queue-depth alarm tied to variant miss rate.
• Shared-store unavailability → total variant outage, since there is no local fallback by design.
• rc-level container compilation breaks (already observed) → deploy-time failure, caught only by building the full container in CI.
• auto_rotate / strip_metadata correctness regressions → EXIF orientation wrong or metadata silently dropped; needs visual regression coverage on a fixture set.

Ramp-up. Meaningful. Our engineers need PHP 8.3, intervention/image v4 (a major version with its own API changes), and — for the sidecar option — enough Symfony to operate a second service: container compilation, Messenger workers, and the CLI warm/remove commands. Estimate a spike of one engineer for one to two weeks to reach a confident build/buy/borrow recommendation, plus separate platform work for the shared variant store and the binary provisioning in our images.

TPM recommendation. Track, do not adopt. Harvest the content-addressing design and the intervention/image v4 upgrade now; keep the sidecar prototype scoped to staging; revisit at 2.0.0 stable with a concrete build-vs-sidecar comparison. The package is architecturally sound and solving a real problem, but it is a pre-release Symfony bundle being evaluated by a Laravel shop — the gap is structural, not a matter of waiting one more rc.