- Is mael/intervention-image-bundle compatible with Laravel?
- No. It is a Symfony bundle that registers intervention/image in a Symfony dependency injection container through a bundle class and YAML or XML service configuration. Laravel has no bundle system, so none of its public surface (bundle registration, the Symfony Configuration tree, service IDs) maps onto Laravel's container lifecycle. You can install it with Composer, but nothing will bootstrap it in a Laravel app.
- Why can't I use a Symfony bundle inside a Laravel application?
- Bundles rely on the Symfony kernel, DI extensions, and the Configuration tree to register and validate services, and Laravel's container never runs that machinery. Laravel instead uses service providers, facades, and config/*.php arrays, with a Manager and driver pattern for multi-driver libraries. There is no shim that makes bundle registration meaningful in Laravel, so the package has no role in the dependency graph.
- What should I use instead for image resizing and cropping in Laravel?
- Depend on intervention/image directly, optionally paired with a maintained Laravel-native wrapper such as intervention/image-laravel. That gives you the same GD and Imagick driver abstraction and the same fluent resize, crop, and encode API without carrying an unmaintained Symfony shim. For greenfield code, type-hint Intervention\Image\ImageManager directly so the abstraction you own is the one you can maintain.
- How do I install and configure Intervention Image in a Laravel app?
- Require the package with Composer, then add a small service provider that binds an ImageManager singleton using the driver from config. Publish or hand-write a config file for driver selection, encoder quality, and cache or storage paths. Optionally add a facade for ergonomics, though constructor injection of the manager is usually cleaner and easier to test.
- Which driver should I choose, GD or Imagick?
- GD is ubiquitous, easy to install in container images, and sufficient for resizing, thumbnails, and WebP output. Imagick is heavier but handles EXIF orientation, CMYK, and PDF-adjacent work better. Make that call explicitly from your requirements rather than letting a stale Composer constraint decide it for you, and verify the extension is present in every runtime image.
- How much work is it to replace this bundle with a Laravel service provider?
- Hours, not days. The bundle's real functionality is a singleton binding plus a config array for driver, quality, and paths, which is straightforward to reproduce in a provider. Add a thin ImageService or facade if you want shorter call sites. The effort is dominated by requirements gathering, not by the integration code itself.
- Is mael/intervention-image-bundle still maintained?
- The last release was on 2020-06-07, roughly five years ago, with one GitHub star and no dependents. There is no community vetting, no informal support channel, and no production evidence in the form of reference implementations. It is MIT licensed, so forking is legally clean, but someone would have to own that fork, and if nobody will, adoption is not viable.
- Does this bundle work with PHP 8 and intervention/image v3?
- Almost certainly not without changes. Intervention Image v3 was a breaking rewrite that introduced driver objects and changed ImageManager, so a bundle released in 2020 almost certainly assumes v2 semantics and transitive constraints that will fight modern PHP and Laravel releases. Verify the PHP constraint, the intervention/image major version, and extension availability before considering it at all.
- How do I migrate existing code that resolves this bundle's service IDs?
- Treat it as a compatibility shim rather than a migration. Define an ImageManagerInterface binding in a Laravel service provider, alias the legacy service name to that binding, and let existing call sites resolve unchanged. This is appropriate only when the blast radius is small and the legacy code is not worth touching yet.
- How do I test image resizing and cropping in a Laravel app?
- Generate small fixture images or use Storage::fake plus temporary files, run them through the manager, and assert resulting dimensions and MIME types with getimagesize or by reading the output through Intervention itself. Write a test that the container resolves the manager to the expected driver so config regressions fail fast. Keep image processing behind a feature flag so the upload and media pipeline can be verified incrementally in production.