Weave Code
Im Bundle Laravel Package
leapt/im-bundle
LeaptImBundle integrates the Imagine image manipulation library into Symfony, letting you define reusable filters for resizing, cropping, and thumbnailing images. It provides cached, on-demand image generation and Twig helpers so templates can serve optimized images with minimal configuration.
Imagemagick wrapper for Symfony. Allows you to use all the convert/mogrify power, from your controller or your templates.
Frequently asked questions about Im Bundle
- Does leapt/im-bundle work with Laravel?
- No. LeaptImBundle is a Symfony bundle whose deliverable is a dependency-injection extension, service definitions and a Twig extension, all of which assume the Symfony kernel, bundle registration in bundles.php or AppKernel, and a Twig templating layer. None of that scaffolding is consumable in a Laravel application, since Laravel's service provider lifecycle, config repository and Blade compiler do not map onto Bundle::boot(), the Configuration tree or Twig filters. The genuinely portable part is small: a thin wrapper that shells out to ImageMagick, resolves an output path in a cache directory and returns the derived file. Realistically you would re-implement that in a few hundred lines rather than integrate the bundle.
- How do I install and register LeaptImBundle in a Symfony application?
- Install it with Composer, then register the bundle in your kernel or bundles.php so its DI extension and Twig extension are loaded. Configure your Imagine adapter, image profiles, filters and cache path in the bundle configuration, and make sure the cache directory is writable by the web server. Setup is intentionally minimal, but it is entirely Symfony-specific: there is no analogous registration path for Laravel.
- How do I generate thumbnails on the fly with the Twig helpers?
- The bundle exposes Twig helpers so templates can request resized, cropped or thumbnailed variants of a source image without any controller code, and the generated derivative is cached on first request. Subsequent renders reuse the cached file, keeping template logic clean and image handling consistent across the application. Check the README for the exact helper signature and profile names, since these depend on how you define your filters.
- Which Imagine adapters does LeaptImBundle support?
- It supports multiple Imagine adapters, notably GD and Imagick, selected through configuration. The adapter choice determines the runtime requirements: GD needs the PHP extension, while Imagick needs both the extension and a compatible ImageMagick installation on the host. Imagick generally gives better quality and more filter options but brings the larger operational footprint.
- Is leapt/im-bundle affected by a shell command injection vulnerability?
- Yes, for older releases. Version 6.1.0 shipped a fix for shell command injection in the Wrapper and ClearCommand plus a regex injection flaw in ImExtension, so every release up to and including 6.0.0 is exposed if any argument can be influenced by user input. No CVE or GHSA identifier appears in the release notes, so composer audit and Dependabot will not warn teams pinned below 6.1.0. Treat any constraint of ^5, ^6.0 or a lockfile resolving below 6.1.0 as a live remote code execution exposure.
- Which version constraint should I use for leapt/im-bundle?
- Require ^6.1.0 or later as a hard floor, and audit any existing lockfile for a resolved version below 6.1.0. Because no advisory was published, automated scanners give you no safety net here, so the constraint has to be enforced in review. If you plan to port logic out of the package, port from 6.1.0 or later only, since copying an earlier tag imports a known vulnerability into your own codebase.
- What should Laravel developers use instead for image manipulation?
- Use a Laravel-native or framework-agnostic package instead of a Symfony bundle. Intervention Image and spatie/image are the common choices, and league/glide is a good fit if you want URL-driven, cached derivative generation with a Blade-friendly API. All of them integrate through a normal service provider and avoid pulling Symfony http-kernel, dependency-injection, config and twig into a Laravel container.
- How do I test image generation and caching in CI?
- The bundle does not document dedicated testing utilities, so the practical approach is a functional test that renders the Twig helper and asserts that the expected derivative file appears in the configured cache path. Your CI image must include the chosen Imagine adapter and, for Imagick, the ImageMagick binaries with a hardened policy.xml, otherwise tests pass locally and fail in the pipeline. Note that test coverage in the project has historically been thin, with skipped tests only recently re-enabled in 6.1.0.
- Is leapt/im-bundle actively maintained and safe for production?
- Adoption is effectively zero: around five stars, no dependents and a single maintainer, so there is no production corpus to infer edge-case behaviour from and you would be the first meaningful consumer. Version 6.1.0 does show modest positive signals, including Dependabot, PHPStan baseline upkeep, Zizmor workflow hardening and re-enabled tests, which suggests active hygiene rather than a rotting repo. The MIT licence is permissive, so forking is legally clean if you need to take ownership.
- Can I use leapt/im-bundle outside Symfony, or reuse its code in Laravel?
- You cannot use the bundle outside Symfony, because its services, configuration tree and Twig extension are all wired to the kernel. You can, however, reuse the idea: delegate image work to the ImageMagick CLI and cache derived assets on disk, implemented behind your own interface using symfony/process or Laravel's Process facade. At that point the package is a reference implementation rather than a dependency, so keep ImageMagick hardened with a strict policy.xml and pass arguments as an array rather than a concatenated shell string.
Weaver
How can I help you explore Laravel packages today?