- Is jlm/aws-bundle compatible with Laravel?
- No. jlm/aws-bundle is a Symfony2 bundle, not a Laravel package. It has no service provider, facade, or publishable config, and it relies on Symfony dependency injection and bundle registration that Laravel does not use. You would need a custom bridge to boot its Symfony container inside Laravel, which is not recommended.
- Can I install jlm/aws-bundle in a Laravel 10 or 11 application?
- Installation will almost certainly fail. The bundle depends on AWS SDK for PHP 2.x and Guzzle 3, which target PHP 5.3 to 5.6 and conflict with the PHP 8.2 or 8.3 and modern dependency constraints used by Laravel 10 and 11. Even a forced install would hit fatal errors from removed PHP functions and incompatible Guzzle and PSR layers.
- What PHP versions does jlm/aws-bundle support?
- It targets PHP 5.3 through 5.6 through its AWS SDK 2.x and Guzzle 3 dependencies. It is not compatible with PHP 7.x or PHP 8.x without forking and rewriting both the dependency injection glue and the SDK boundary. The package was last released in 2014 and is archived.
- Does jlm/aws-bundle use AWS SDK for PHP v3?
- No. It wraps AWS SDK for PHP 2.x, using namespaces like Aws\Common\* and factory methods such as Aws\S3\S3Client::factory(). Those APIs were removed in SDK 3.x, so the bundle does not match the SDK version Laravel's native AWS integrations use.
- How do I configure AWS credentials and region with jlm/aws-bundle?
- Configuration is done through Symfony bundle config, for example config.yml under a jlm_aws key, and Symfony's DI extension. There is no Laravel config file or environment-based publishing step. In Laravel you would instead configure credentials through config/services.php or environment variables and bind Aws\Sdk in a service provider.
- Can I use jlm/aws-bundle for S3, SQS, or SES in Laravel?
- You should not. Laravel already provides native S3 filesystem, SES mail transport, and SQS queue drivers that wrap aws/aws-sdk-php v3 directly. The bundle's Symfony service wiring does not plug into Laravel's filesystem, mail, or queue managers. Use Laravel's-native drivers or inject typed SDK v3 clients where you need lower-level control.
- Is jlm/aws-bundle maintained or safe for production?
- No. The repository is archived, the last release was 2014-02-14, and it has zero stars and zero dependents. There is no security patching, no CVE response, and no maintainer. Using it in production means you own every future change, including PHP minor-version breakage and AWS API drift.
- What are the alternatives to jlm/aws-bundle for Laravel?
- Use Laravel's built-in AWS integrations: the S3 filesystem driver via Flysystem's AwsS3V3 adapter, the SES mail transport, and the SQS queue driver. For anything else, bind Aws\Sdk as a singleton in a service provider and inject typed clients. That approach is roughly 40 lines and replaces the bundle with something maintainable and compatible with current PHP and Laravel versions.
- How do I migrate from jlm/aws-bundle to native Laravel AWS support?
- Inventory the Symfony service IDs the bundle registers and the ones your application actually consumes. Map each to its SDK v3 equivalent, replace S3, SQS, and SES usage with Laravel's native drivers where sufficient, and keep direct SDK clients where you need more control. Then delete the bundle and its Guzzle 3 dependency tree, and add integration tests against a real bucket or queue in a non-production account.
- How do I test AWS integrations in Laravel without jlm/aws-bundle?
- Use Laravel's native fake and mock facilities, such as Storage::fake('s3'), Mail::fake(), and Queue::fake(), or mock the Aws\Sdk client in your service provider bindings. For integration tests, point the SDK at a non-production AWS account or a local emulator like LocalStack. The bundle's Symfony-style test setup does not carry over to Laravel's testing helpers.