Weave Code
Tiny Png Bundle Laravel Package
setono/tiny-png-bundle
A Symfony bundle that integrates the TinyPNG API to automatically compress and optimize PNG and JPEG images, helping reduce file sizes and improve page load performance with simple configuration.
Setono TinyPngBundle is a Symfony bundle that integrates the TinyPNG API to automatically compress PNG and JPEG images in your application. It wraps the official TinyPNG PHP client in Symfony's service container, giving you simple configuration and ready-to-use services for shrinking image file sizes without visible quality loss.
- Seamless Symfony integration with bundle configuration for your API key
- Autowired TinyPNG client service ready for injection
- Compress PNG and JPEG files to reduce storage and bandwidth
- Ideal for optimizing uploaded media and asset pipelines
- Minimal setup, PSR-compliant and Composer-installable
Frequently asked questions about Tiny Png Bundle
- Does setono/tiny-png-bundle work with Laravel?
- No. It is a Symfony bundle that depends on symfony/config, symfony/dependency-injection and symfony/http-kernel bundle bootstrapping, so it will not install or run in a Laravel app without pulling in Symfony's container and writing your own bootstrapping. At that point you are better off using the official tinify/tinify SDK directly behind a Laravel service provider. The only reusable asset is its small design pattern, which you can reproduce in an afternoon.
- How do I install and configure setono/tiny-png-bundle?
- In a Symfony app you run composer require setono/tiny-png-bundle, register the bundle in bundles.php, and set the TINIFY_API_KEY environment variable that its configuration tree reads. Then inject the provided compressor service where you need it. Beyond code you need a TinyPNG account with a provisioned API key per environment and outbound HTTPS egress to api.tinify.com.
- Which Symfony and PHP versions does it support?
- The last release was 2022-02-11, which almost certainly predates Symfony 6.4/7.x and PHP 8.2/8.3 test coverage. Expect Composer constraint conflicts, and do not paper over them with --ignore-platform-reqs. Verify the package against your target matrix before adopting, or budget for a fork on day one.
- What does this bundle give me over using tinify/tinify directly?
- Not much: a DI extension, a configuration tree for the API key, and service definitions that wrap the official SDK behind a compressor interface. That is a few hundred lines of glue, with the substantive logic living in tinify/tinify and TinyPNG's REST API. If the answer to "what does it add?" is configuration sugar, skip the dependency.
- Is image compression synchronous in the request path?
- The bundle adds no async handling on top of the SDK, so calls run synchronously wherever you invoke the compressor. Because TinyPNG calls are network-bound, rate-limited and cost money, you should dispatch compression to a queue worker rather than doing it during a user request. Keeping it out of the request path is your responsibility, not the package's.
- What are the TinyPNG API costs and quota risks?
- TinyPNG is a paid third-party API with a limited free tier and per-image pricing, so quota exhaustion, outage and key rotation are your real failure surface. The bundle does not add retry, backoff or quota telemetry. Project your monthly image volume first and size the plan tier accordingly before adopting.
- Is this package safe to use in production?
- Adoption signal is effectively zero: 0 stars, 0 dependents, and no release since February 2022, with a single agency maintaining it for its own ecosystem. There is no production user base to have surfaced edge cases and no community to fix them. Treat it as unaudited code with write access to your service container; it is small enough to read in full, and you should, plus pin exact versions and commit the lockfile.
- What is the Laravel alternative to this bundle?
- Use the official tinify/tinify SDK behind a Laravel service provider and your own ImageCompressor contract, then run compression from a queued job and a filesystem post-processing hook. If you do not need the TinyPNG API specifically, a local-binary optimizer such as spatie/image-optimizer avoids per-image API costs and third-party outages entirely. Both approaches skip the Symfony container dependency.
- How do I handle API failures, retries and quota exhaustion?
- The bundle does not provide retry, backoff, quota telemetry or async handling, so implement those in your own adapter around the SDK. Add bounded retries with backoff, per-environment key rotation, and a failure-tolerant pipeline that can skip compression rather than break a deploy or upload. Monitor compression volume against your TinyPNG plan so you notice quota burn before users do.
- Which compressor interfaces does it expose, and will they fit LiipImagine, Flysystem or Sylius?
- It exposes compressor services that typically implement Setono's own compressor interface, so check whether those signatures match your pipeline before committing. If you use LiipImagineBundle, a Flysystem post-processor or Sylius, a thin wrapper is usually enough, but that wrapper is code you now own. If the interface does not fit cleanly, skip the bundle and adapt tinify/tinify directly.
Weaver
How can I help you explore Laravel packages today?