- Is laelaps/symfony-gearman-bundle a Laravel package?
- No. It is a Symfony bundle that integrates the Gearman job server, and Laravel has no bundle loader. Symfony bundles rely on the Bundle class, Extension::load(), configuration trees, and compiler passes, none of which Laravel consumes. There is no path to composer require plus auto-discovery in a Laravel app, and integration means rewriting the wiring layer as a Laravel service provider.
- Can I install this bundle in Laravel with Composer auto-discovery?
- No. The package has no Laravel package discovery, no service provider, no publishable config file, no facades, and no illuminate/support integration. You would have to manually register classes and reimplement the configuration in Laravel idioms. At that point the bundle contributes almost nothing beyond a reference implementation.
- What Symfony and PHP versions does this Gearman bundle support?
- It targets Symfony 2.x-era APIs and PHP 5.3 to 5.5 idioms, with the last release on 2013-08-12. The code is untyped, has no return types, is unlikely to be PHP 8 compatible, and probably uses PSR-0 autoloading. The container APIs it calls, such as old Definition signatures and Reference handling, do not exist in current Symfony, so the version skew is not bridgeable.
- Does this bundle require the PECL gearman extension?
- That is not clear from the package metadata and must be confirmed by reading the source. It may require ext-gearman or it may wrap a pure-PHP client, and this determines whether you inherit a C-extension build dependency. The PECL gearman extension has seen minimal activity for years, and compiling it against modern PHP builds is a recurring friction point, so treat this as a go/no-go check before any design work.
- How do I run Gearman background jobs in a Laravel application?
- If Gearman is a hard constraint, write a small Laravel service provider and config file wrapping a maintained Gearman client directly. That is roughly 200 lines of typed, tested, PHP 8-clean code you own, and it is cheaper and safer than porting the bundle. If the real requirement is just background jobs, use Redis or SQS with Laravel Horizon or Laravel's native queue instead.
- Is this bundle still maintained and safe for production today?
- It has 14 stars, 0 dependents, and no forks validating modern PHP, with the last release in 2013. Its own description says it is finished and ready for production, but that statement comes from a Symfony 2 era. The MIT license is clean, so this is a technical and strategic risk rather than a legal one, and you would be the maintainer from day one.
- What are the Laravel alternatives to Gearman for asynchronous task processing?
- Laravel's native queue supports Redis, SQS, database, and Beanstalkd drivers, and Horizon adds monitoring and supervision for Redis queues. Adopting that removes the gearmand daemon, the C extension, and this package in one move. The only exception is a hard constraint that an existing Gearman cluster must be consumed.
- Can I use this Symfony bundle alongside Laravel's queue system and Horizon?
- Not in any integrated way. The bundle does not participate in Laravel's worker lifecycle, retry semantics, or failed-job handling, and it ships no test suite runnable on modern PHP. Running it next to Horizon means operating a second job system with its own daemon and deployment burden. Pick one transport rather than mixing both.
- How do I test Gearman workers if I adopt this bundle?
- There is no test suite runnable on modern PHP and no Laravel testing helpers. You would need to boot gearmand in CI and test against a real server, or wrap the client behind an interface you can fake. A clean-room Laravel provider lets you inject a fake Gearman client and test dispatch logic without the daemon, which is a strong argument for building your own layer.
- How much effort is it to port this bundle to Laravel?
- Feasibility is low. The bundle's substance is DI service definitions for a Gearman client and worker, a config tree for server and worker options, and a couple of console commands, while the real work is done by the underlying Gearman client or extension. A shim would be more code and more risk than a clean-room service provider. Sequence it as a half-day source review gate, a one-day environment spike for gearmand or PECL gearman on your target PHP version, and only then a two-to-three-day internal package with tests.