- What is zenstruck/image used for in a Laravel application?
- It is a thin image file wrapper: an Image value object that opens a file, applies a transformation through an injected callable, and saves or deletes the result. In Laravel you use it behind an application service or queued job, often reading and writing through the Storage facade. It gives your code a stable contract while keeping GD, Imagick, or Intervention Image details out of your domain code.
- How do I install zenstruck/image in a Laravel project?
- Install it with Composer using composer require zenstruck/image. The package is PSR-4, MIT licensed, and targets PHP 8.x with minimal transitive dependencies. There is no Laravel service provider or config file to publish, so you can instantiate it directly or bind an adapter in your container.
- Does zenstruck/image support Laravel 10, 11, or 12?
- It is Laravel-version-agnostic because it has no framework coupling, service provider, or config. The real compatibility surface is your PHP version floor and the image backend library you choose, such as GD, Imagick, or Intervention Image v2 versus v3. Pin those explicitly and assert the same versions in CI and production containers.
- Do I need to configure a service provider or publish config for zenstruck/image?
- No. The package is deliberately thin and has no Laravel-specific wiring to register. You integrate it by wrapping it in a small application service or job, for example an ImageProcessor, and binding that service in your container if you want dependency injection. This keeps the package an implementation detail rather than a framework dependency.
- Should I use GD or Imagick as the backend for zenstruck/image?
- You choose the backend; zenstruck/image only provides the file lifecycle and transformation seam, while the callable does the pixel work. Standardize on one backend across local, CI, and production, because GD and Imagick builds can differ in behavior and format support. WebP and AVIF support depend on how GD or Imagick was compiled on the host, not on this wrapper.
- Can zenstruck/image resize, crop, convert to WebP, or watermark images?
- The wrapper gives you an open, transform, and save/delete contract rather than a rich transformation DSL. You implement resize, crop, format conversion, watermarking, or EXIF stripping inside the transformation callable using Intervention Image, Imagick, or GD. If you need a fluent filter API or signed URL routing, pair it with a dedicated imaging package or add that layer yourself.
- Is zenstruck/image safe to use in production with queued jobs?
- It can work well in queued workers as long as your transformation callback is pure enough and the chosen backend is installed everywhere. Pay attention to temp-file lifecycle semantics when a transformation throws, and decide whether synchronous request-time processing is required or all transformations can be queued. Test failure mid-transform and confirm that intermediate files are cleaned up.
- How do I test code that uses zenstruck/image?
- Because the transformation is an injected callable, you can fake it in tests and assert that the image was opened, transformed, and saved or deleted as expected. Use temporary directories or a fake Storage disk, and include tests for successful transformation, failure during transformation, and cleanup of temp artifacts. There are no Laravel-specific test helpers to learn because the package is framework-agnostic.
- What are alternatives to zenstruck/image for image manipulation in Laravel?
- Common alternatives include Intervention Image, league/glide, spatie/image, and a small in-house wrapper around GD or Imagick. zenstruck/image is not a replacement for a full manipulation library; it is the file lifecycle seam around one. Choose it when you want a minimal, swappable backend contract, and pair it with a richer library for complex filters or on-the-fly URL generation.
- Is zenstruck/image actively maintained, and what is the maintenance risk?
- The assessed risk is mainly project-level: around 31 stars, a single maintainer, an unspecified repository link, and no LTS or commercial backing. The mitigating factor is that the abstraction is small and shallow, so lock-in is low and a fork or in-house reimplementation is a days-not-weeks exercise. Pin to a known-good version, watch releases, and document who owns the fork if upstream goes dormant.