Progressive Image Bundle Laravel Package

Product Decisions This Supports

• Image pipeline roadmap: Supports investing in responsive/progressive image generation as a platform capability rather than one-off controllers or custom scripts. The 2.0 Variant pipeline adds deterministic, content-addressed variants, so product teams can reason about image URLs as stable, cacheable outputs.
• Build vs. buy: Strong case for buying/adopting when the team is on Symfony and wants Liip parity without owning the full generation pipeline. The RC removes the LiipImagineBundle dependency, adds pgi_filter()/PHP-side URL resolution, an on-the-fly resolve route, and progressive-image:variant:warm/:remove CLI commands.
• Feature prioritization: New filters (grayscale, negative, auto_rotate, paste, relative_resize), encoding options (progressive, strip_metadata), and real post-processing (jpegoptim, pngquant, cwebp, avifenc) let PMs prioritize image quality, format modernization, and page-weight reduction without bespoke work.
• Operational model choice: The three generation strategies—sync, terminate, and async via Messenger—let PMs/product owners trade off request latency vs. background processing infrastructure. This affects UX SLAs and ops cost.
• Migration/consolidation: Relevant for teams currently on LiipImagineBundle or scattered image logic. The release includes a Liip migration guide and full parity claims, making dependency consolidation a viable roadmap item.
• Caveat for Laravel products: This is a Symfony bundle, not a Laravel-native package. For a Laravel roadmap, treat it as a signal/benchmark or a possible standalone PHP integration only if the team explicitly accepts Symfony coupling.

When to Consider This Package

• Consider it when the product runs Symfony 6.4, 7.4, or 8.1+ on PHP 8.3+ and needs progressive/responsive image generation, deterministic variants, async generation, and post-processing.
• Strong fit when migrating from LiipImagineBundle or when the team wants Liip-like Twig/PHP URL resolution, warm/remove CLI tooling, and a documented migration path.
• Consider it for multi-worker/queue-based environments where content-addressed variants reduce coordination and improve CDN/cache behavior.
• Look elsewhere if the product is Laravel-native and expects first-class Laravel integration; none is indicated here.
• Look elsewhere if the team cannot move to PHP 8.3+, requires a stable final release, or cannot tolerate breaking changes during the 2.0 RC period.
• Be cautious if the team needs zero-config installation today: the Symfony Flex recipe is submitted, not necessarily merged. Also pin the exact RC version if used in production.

How to Pitch It (Stakeholders)

• To executives: This is a pre-release of a rewritten image pipeline that can reduce custom image infrastructure, improve image delivery through deterministic/cache-friendly variants, and remove a prior LiipImagineBundle dependency. It supports modernization around WebP/AVIF and post-processing, but it is not yet a final stable release.
• To engineering: The 2.0 RC introduces a DDD-style Variant pipeline, content-addressed generation, sync/terminate/async strategies, new filters, post-processing tools, CLI warm/remove commands, and Liip parity. The trade-off is meaningful platform requirements: PHP 8.3+, Symfony-specific integration, and likely breaking changes before 2.0.0 final.
• To a Laravel team: Do not pitch this as a Laravel package. Pitch it only if there is a Symfony service or a deliberate standalone PHP integration; otherwise use it as a benchmark for image-pipeline expectations and evaluate Laravel-native alternatives.