Product Decisions This Supports
- Build vs. buy for background processing. This package frames a queue-architecture decision: standardize on a Redis-backed Resque model (and own it) or move to first-party tooling. The evidence — 12 stars, 0 dependents, and a self-declared "not maintained" description — argues decisively for first-party (Laravel Horizon + native queues; Symfony Messenger). The package itself is the artifact that lets you close the decision, not reopen it.
- A documented "no-go" for the dependency register. Written evidence in an architecture review or vendor-risk log. An explicit rejection is cheaper than re-litigating the same candidate next quarter.
- Legacy migration scoping. If part of the estate still runs Symfony 2.x/3.x on php-resque, this maps the migration surface: job classes, payload shapes, queue naming, failure backend, worker lifecycle, DI wiring. That is how you size a move to Messenger or Laravel queues.
- Observability roadmap input. Resque ships no dashboard or metrics, and the bundle adds none. That forces a real roadmap decision — build a Horizon-equivalent or accept blind queue operations — instead of burying it as a footnote.
- Platform-fit diligence / data-quality ticket. This is a Symfony bundle surfaced as a Laravel package. That is a recommendation-pipeline defect (no framework-compatibility or maintenance check), and arguably more valuable to fix than anything the package offers.
- Narrow, frozen-stack reference only. A legitimate reference implementation for queue/worker wiring in a legacy Symfony app; not a candidate for new feature work. Also read the 0.86 "opportunity" score as whitespace — the niche is underserved — not as an adoption signal.
When to Consider This Package
Consider it only if all of the following hold:
- An existing Symfony 2.x/3.x application already runs php-resque and you need bundle-level configuration/DI glue to keep it alive.
- You are prepared to fork and vendor it, accepting permanent maintenance ownership.
- Dependency and PHP version constraints match your frozen stack exactly.
- No internal policy requires maintained upstreams, security patch SLAs, or vendor support.
Look elsewhere when:
- Laravel. The native queue + Horizon cover Redis queues, retries, backoff, metrics, and a failed-job UI. There is no gap to fill — and this bundle is not framework-compatible anyway (no bundle loader, no YAML container config, different console/event contracts).
- Symfony 4+. Symfony Messenger is first-party, maintained, and supersedes this transport model.
- You need retries, scheduling, unique jobs, delivery guarantees, or a UI out of the box. Resque relies on a thin, largely abandoned plugin ecosystem, and its default pop-before-execute design loses jobs on worker crash (no ack/visibility timeout), which fails any at-least-once requirement.
- You need PHP 8.1+, security patches, or a support contract. "Not maintained" is a hard stop for most organizations.
- You need community support. Zero dependents means zero peers hitting your bugs; every issue becomes yours.
How to Pitch It (Stakeholders)
To executives: This is a 12-star, self-declared unmaintained Symfony bundle with no known dependents — mis-surfaced to us as a Laravel package. It does not clear our bar for production dependencies: no vendor, no security patching, no community, no support path. Recommendation: reject, and standardize queueing on first-party tooling (Horizon for Laravel, Messenger for Symfony). The honest cost of adoption isn't integration work; it's owning a permanent fork plus building the monitoring and reliability layers Resque lacks. Note the high "opportunity" score reflects an underserved niche, not a good buy — the right answer to that gap is first-party tooling, not a dependency on an abandoned wrapper. The only defensible exception is short-lived interoperability with an existing Ruby Resque deployment, and even then the correct move is a small, owned adapter with a defined exit plan.
To engineering: Treat this as a reference, not a dependency. If you're on a legacy Symfony + php-resque stack, use it to chart a migration to Messenger or Laravel queues (inventory jobs and payloads, port to ShouldQueue/dispatch(), dual-run behind a flag, then decommission). Otherwise it's a distraction: unmaintained upstream, fork-based process model that is fragile under FPM/containers, PHP-serialized payloads that make refactors deploy-hazardous, and silent job-loss failure modes you'd have to compensate for manually. Separately, flag the pipeline defect — a Symfony bundle reaching us labeled "Laravel" means our catalog isn't checking framework compatibility or maintenance status, which is a bigger risk than this one result.