- Can I use glit/resque-bundle in a Laravel application?
- No. glit/resque-bundle is a Symfony2 bundle (Glit\ResqueBundle) that registers php-resque services into the Symfony dependency injection container and console. Laravel has no bundle registration, no AppKernel, and no Symfony DI container to hook into, so the package cannot be installed or bootstrapped as-is. The only workable approach is to skip the bundle entirely and wire php-resque as a standalone Composer dependency with your own Laravel service provider.
- Does glit/resque-bundle support Laravel 10, 11, or 12?
- It does not support any version of Laravel. The package targets Symfony 2.x, a framework generation that reached end-of-life with Symfony 2.8 in November 2018, and its PHP constraint likely caps at PHP 5.6 or 7.0. Modern Laravel 10, 11, and 12 require PHP 8.1 or newer, so Composer resolution will fail unless you resort to --ignore-platform-reqs, which is not viable in production.
- What PHP versions does glit/resque-bundle require?
- Based on its Symfony2-era origin, expect a constraint in the PHP 5.3 to 5.6 range, possibly up to 7.0. There is no indication of PHP 8.x compatibility, and the package has no PSR-4 autoloading guarantee. Running it on PHP 8.1 or later is unsupported and likely to hit deprecations or fatal errors in php-resque and its dependencies.
- How do I install glit/resque-bundle with Composer?
- Installation only makes sense inside a Symfony2 application, where you would run composer require glit/resque-bundle and register the bundle in AppKernel. There is no Laravel service provider, facade, or config file to publish, so php artisan vendor:publish and package discovery will not help. For Laravel, use a maintained queue package or Laravel's built-in Redis queue driver instead.
- What is the difference between Resque and Laravel's Redis queue driver?
- Resque uses Redis lists with resque:worker:* keys and a fork-per-job worker model, plus the resque-web dashboard for inspection. Laravel's Redis queue driver integrates with ShouldQueue jobs, tries, backoff, job batching and chaining, rate limiting, encrypted payloads, and Horizon monitoring. Resque has no native equivalents for most of those Laravel semantics, so retries and failure handling would require custom glue code.
- Is glit/resque-bundle still maintained and safe for production?
- There is no meaningful maintenance signal: zero stars, zero dependents, and no issue triage or security patching. The underlying Symfony2 stack is end-of-life, so you would become the sole steward of a fork responsible for PHP and Redis compatibility fixes. For a production Laravel application, that risk profile is generally not defensible.
- How do I migrate Resque jobs from Symfony2 to Laravel queues?
- Treat the bundle as a reference implementation: extract the job class definitions, queue-name conventions, and worker bootstrap logic, then re-implement them as Laravel Job classes. Replace Resque::enqueue() calls with dispatch() and worker invocations with php artisan queue:work --queue=<name>, preserving queue names so external enqueuers keep working during cutover. If other systems write Resque-format payloads directly into Redis, run a short-lived relay that pops those payloads and dispatches Laravel jobs.
- Does glit/resque-bundle work with modern Redis 6 or 7?
- That is a real compatibility concern. Older php-resque releases may rely on Redis commands or behaviors that Redis 6 and 7 deprecate or restrict, and Resque's fork-per-job worker model is fragile in containerized or process-constrained environments. Any migration should include load testing against your target Redis version before relying on it.
- What are the best Laravel alternatives to glit/resque-bundle for background jobs?
- For Redis-backed queues in Laravel, the native Redis queue driver paired with Horizon provides named queues, priority ordering, retries, and a monitoring dashboard with first-class framework semantics. The database queue driver suits smaller workloads, and Amazon SQS is a solid managed option. Choose standalone php-resque only if you must interoperate with an existing Ruby Resque deployment, and even then keep the Symfony bundle out of the dependency graph.
- How would I test or run Resque workers alongside a Laravel app?
- You cannot run the bundle's workers inside Laravel because its worker bootstrap is a Symfony console integration; running a parallel Symfony2 process purely for workers is almost never a defensible architecture. If you adopt standalone php-resque, test job classes in isolation and use Laravel's Queue::fake() for code that dispatches Laravel jobs. For real coverage, assert against a disposable Redis instance rather than mocking queue internals.