Weave Code
Filejet Bundle Laravel Package
filejet/filejet-bundle
FileJet Bundle integrates the FileJet file upload and delivery service into Symfony/PHP applications, providing configuration and service wiring for uploads, transformations, storage, and asset delivery with minimal setup, helping developers add FileJet-powered file handling quickly.
Symfony bundle for FileJet service
Frequently asked questions about Filejet Bundle
- Can I use filejet/filejet-bundle in a Laravel application?
- Not directly. This package is a Symfony bundle: it relies on Symfony bundle registration, a DependencyInjection extension and a Configuration tree, none of which Laravel's container consumes. The workable path is to require FileJet's PHP SDK directly and write a small Laravel service provider plus facade, using this bundle as a reference implementation for config keys, endpoint defaults and client construction.
- How do I install and configure filejet/filejet-bundle in Symfony?
- Install it with composer require filejet/filejet-bundle, enable the bundle in config/bundles.php, then supply credentials such as the API key, container or bucket identifier and CDN base URL through environment variables in the bundle configuration. After that you can inject the FileJet client service into controllers and application services. Confirm the exact configuration keys against the bundle's Configuration tree, since they are not reproduced in the overview.
- Which Symfony and PHP versions does filejet/filejet-bundle support?
- The supported Symfony and PHP ranges are not stated in the provided material, so read the composer.json constraints before committing. Symfony 5 to 6 to 7 migrations have repeatedly broken bundles that pin DI or event-dispatcher APIs, so check how recently those constraints were widened. Also verify the minimum PHP version matches your runtime.
- Is filejet/filejet-bundle actively maintained and safe to use in production?
- The adoption signals are weak: zero stars, zero dependents and a single vendor maintainer, with no third-party issue history or evidence of production use outside the vendor's own integrations. That is not proof of poor quality, but it means you get no community hardening. Verify tag signatures, commit history, CI configuration and a changelog, and treat the stated release date as anomalous metadata requiring normal supply-chain diligence.
- What does filejet/filejet-bundle actually contain, just service wiring or also controllers, routes and Twig helpers?
- The overview describes Symfony-native bundle configuration, service wiring, simple uploads and retrieval, configurable credentials and an extensible architecture. It does not confirm whether controllers, routes, Twig extensions or a Flysystem adapter ship with it. That distinction matters: wiring-only can be ported to Laravel in hours, whereas bundled controllers and templates mean reimplementation, so inspect the src and DependencyInjection directories first.
- Is there a standalone FileJet PHP SDK I can depend on without Symfony?
- Yes, effectively: the bundle is a thin convenience wrapper around FileJet's PHP client, and the evaluation explicitly recommends consuming that client directly on Laravel. You construct the client yourself from the same credentials and endpoint defaults the bundle uses. Confirm on Packagist that the SDK is versioned independently and check its Symfony-decoupling and PHP constraints before relying on it.
- Does filejet/filejet-bundle support queued or async uploads, signed URLs and multi-bucket configuration?
- These capabilities are not documented in the material provided. Because the bundle is a thin wrapper, anything FileJet's API supports may be reachable through the underlying client, but the bundle's configuration surface may not expose it. Plan to handle queueing in your own application, for example with Laravel jobs, and verify signed URL and multi-tenant behaviour against the SDK documentation rather than assuming the bundle covers it.
- How locked in am I to FileJet if I adopt this package, and how would I migrate away?
- This is a commercial coupling decision rather than a library choice: the bundle encodes a dependency on a paid third-party file service, and files are among the hardest assets to migrate later. No documented migration path off FileJet is provided. Mitigate by keeping storage keys, transformation rules and delivery URLs behind your own interface so a future backend swap is an adapter change, and ask the vendor for their SLA and deprecation policy.
- How should I test a FileJet integration without hitting the live API?
- Wrap the FileJet client behind your own interface and bind a fake implementation in tests: a container alias in Symfony, or a service provider binding plus facade in Laravel. Assert that your configuration mapping, error handling and URL generation behave correctly against that fake. Keep one small contract test against the real SDK to catch upstream signature changes, and never call the live upload endpoint in CI.
- What alternatives should I consider instead of filejet/filejet-bundle?
- On Laravel, skip the bundle and use the FileJet PHP SDK with your own service provider and facade, or evaluate Flysystem with S3-compatible storage plus a separate image transformation and CDN service. On Symfony, the bundle is a reasonable thin wrapper if you accept the adoption and bus-factor risk. Compare options on migration lock-in, async upload support, signed URLs and multi-tenant configuration before deciding.
Weaver
How can I help you explore Laravel packages today?