Async Bundle Laravel Package

Product Decisions This Supports

• A "do not adopt" decision, made cheaply. This package's own README is a deprecation notice pointing at symfony/messenger and symfony/scheduler. The most valuable product output here is a fast, defensible no — before any engineering time is spent evaluating, prototyping, or wiring it into a roadmap.
• Build vs. buy vs. use-native. The capability it addresses — deferring work, running jobs out of band, scheduling recurring tasks — is commodity infrastructure. Every credible PHP stack now ships this natively (Symfony Messenger + Scheduler; Laravel's queue, bus, and scheduler with Horizon for observability). The decision is not "which async package," it's "why are we adding a third-party bundle for something the framework owns?"
• Migration sequencing, if it is already in the stack. If a legacy service depends on this, the decision becomes: how fast do we get off it, and what breaks if we don't? That is a roadmap item with a real cost and a real risk curve, not a nice-to-have.
• Dependency governance policy. Zero stars, zero dependents, no release since November 2022, archived, and self-declared deprecated is a textbook trigger for an adoption gate. This package is a useful worked example when writing the rule: no new dependency without a maintenance signal — recent release, responsive maintainer, at least one of ecosystem adoption or first-party ownership.
• Scope framing for the underlying use cases. Whatever the original backlog item was — deferred emails and notifications, webhook fan-out, report generation, nightly reconciliation — it still needs an owner and a home. Pick the native mechanism and the use case proceeds; the package was never the value.

When to Consider This Package

Almost never, and never for new work. The narrow legitimate reasons to open this repository:

• Archaeology. You inherited a service that references it and need to understand runtime behavior — retry semantics, persistence, failure handling — so you can reproduce it faithfully during migration.
• Removal planning. You need to inventory call sites and confirm what the replacement must cover before you can delete the dependency.

The criteria that would normally justify adoption — active maintenance, a security response path, recent releases, ecosystem validation, documentation beyond a deprecation banner — all fail outright. Archived status means no upstream fix will arrive, including for a PHP or Symfony major-version incompatibility that lands on your upgrade path. Zero dependents means no community will absorb that work on your behalf.

Look elsewhere, specifically:

• Symfony applications: symfony/messenger for async transport and retries, symfony/scheduler for recurring tasks — the maintainer-endorsed successor pair, first-party, and already covered by Symfony's release and security process.
• Laravel applications: native queued jobs and the task scheduler, with Horizon or a managed dashboard for visibility. Note the context mismatch — this is a Symfony bundle, so evaluating it inside a Laravel codebase was already a signal that the requirement was framed as "find a package" rather than "use the platform."
• Genuine scale or durability requirements: a real broker or managed queue (SQS, RabbitMQ, Redis-backed queues) rather than a thin bundle, if throughput, ordering, or delivery guarantees are the actual constraint.

How to Pitch It (Stakeholders)

To executives — one paragraph. We evaluated a library for background job processing and recommend against it. The maintainers have formally deprecated it, the last release was in late 2022, the repository is archived, and it has no downstream users. The capability itself is not at risk — both Symfony and Laravel provide it as a first-party, supported feature, and the deprecation notice explicitly names the official replacements. Adopting it would introduce unpatched-code and framework-upgrade risk to save no meaningful engineering effort. Recommendation: do not adopt; if it exists anywhere in our estate, schedule a small migration.

To engineering — the practical version. Treat the deprecation notice as the spec. Freeze new usage, inventory existing call sites, and port each to Messenger + Scheduler (or the framework-native queue and scheduler). Expect the port to be mostly mechanical; the real work is confirming behavioral parity on retries, failure handling, and idempotency, which are the places a hand-rolled async layer diverges from a first-party one. Add an automated dependency check — archived, deprecated, or no release in 18 months — so the next one of these is caught by tooling rather than by review.

The ask. Approve (a) a standing policy against new dependencies that are archived or self-deprecated, and (b) a time-boxed migration ticket if the package is present in any live service. Both are small, and both are cheaper now than during a framework upgrade.