Resque Queue Driver Bundle Laravel Package

Product Decisions This Supports

• Framing correction that changes the decision: this is a Symfony bundle, not a Laravel package. Any roadmap item assuming "drop-in Laravel queue driver" is mis-scoped; adopting it in a Laravel codebase would require custom integration work, so treat it as a legacy-Symfony artifact rather than a Laravel dependency.
• Build vs. buy vs. keep: informs whether to invest in a thin in-house Redis queue adapter versus standardizing on a maintained framework primitive (Laravel queues + Horizon, Symfony Messenger). The package itself is effectively a bridge to Resque, a Ruby job system, so "buy" also means "add a Ruby runtime to our ops surface."
• Legacy modernization roadmap: the concrete use case is a Symfony 2/3-era application already running Resque workers that needs a PHP-side producer. That makes it a candidate input to a sunset plan, not a new-feature dependency.
• Vendor and maintenance risk scoring: last release 2018-02-24, 0 stars, 0 dependents, overall health score 0.09. This is decision-grade evidence for a "do not adopt / plan exit" call, and for flagging unpatched security and PHP-version-compatibility exposure to security and platform teams.
• Prioritization signal: a high "opportunity" sub-score (4.16) against a near-zero overall score usually means "clear gap, no credible solution here" — i.e., the need (Redis-backed background jobs) is real, but this package is not the answer. Route the roadmap item to a maintained alternative instead.
• Use-case scoping: viable only for asynchronous work that tolerates at-least-once delivery and no native PHP scheduler — emails, thumbnail/image processing, exports, webhook fan-out — in an environment where Resque is already operational.

When to Consider This Package

Consider it only when all of the following hold:

• You are maintaining an existing Symfony application (not Laravel) pinned to a PHP/Symfony generation this bundle supports.
• Resque and a Ruby runtime are already running in production, with operational ownership and monitoring in place.
• You need a minimal PHP-side enqueue driver and are willing to vendor/fork and own the code, since upstream is dormant.
• A migration to Messenger or another maintained queue is explicitly out of scope for the current cycle.

Look elsewhere when:

• You are on Laravel. Use the native queue system with Redis and Horizon; no reason to introduce a Ruby dependency or an unmaintained Symfony bundle.
• You are on modern Symfony. Use Symfony Messenger with the Redis or Doctrine transport — first-party, maintained, and compatible with current PHP versions.
• You need active maintenance, security patching, current PHP support, or a support contract. Zero dependents and an eight-year-old release mean you are the maintainer if you adopt.
• Your team has no Ruby/Resque operational experience. The hidden cost is a second language runtime, second set of deploy artifacts, and second failure domain.
• You need exactly-once semantics, native scheduling, or first-class observability. None of that comes from a thin driver; it comes from the surrounding platform.

How to Pitch It (Stakeholders)

To executives: This package is a small, MIT-licensed adapter that lets a Symfony application push background jobs into Resque, a Ruby-based queue backed by Redis. It is not a Laravel package, and it is not maintained — the last release was in 2018, with no dependents and negligible community traction. Recommendation: do not adopt, and if we already depend on it, budget a migration to a first-party queue (Laravel Horizon or Symfony Messenger). The strategic value is near zero; the ongoing cost is a permanent maintenance and security-patching obligation plus a second runtime to operate.

To engineering: Treat it as a legacy compatibility shim, not a platform choice. It is thin by design — its only real function is serializing jobs into Resque's Redis format — so replacing it is low-effort and low-risk compared with keeping it. Key concerns: no upstream fixes, PHP/Symfony version drift, an added Ruby/Resque operational surface with its own deploy, monitoring, and failure modes, and at-least-once delivery semantics that product code must be idempotent against. If we must keep it temporarily, fork and vendor it, pin versions, and put an exit ticket on the roadmap with an owner and a date.