Worker Bundle Laravel Package

Product Decisions This Supports

• Build vs. adopt vs. vendor for async infrastructure. The package sits in the "worker lifecycle" layer — the part of a job system that handles process startup, graceful shutdown, signal handling, and memory limits around a long-running consumer. That is commodity infrastructure; a PM's job is to keep it out of the product's differentiated surface and choose the cheapest reliable owner for it.
• Stack direction. The *Bundle naming and Symfony-style packaging suggest this is a Symfony bundle, not a Laravel package. That's a real roadmap input: it either confirms a Symfony-first backend or rules itself out entirely if the team is on Laravel (where Horizon / the native queue worker is the incumbent).
• Reliability roadmap for async pipelines. If we were shipping order processing, email/webhook fan-out, media transcoding handoffs, chunked ETL, or rate-limited third-party syncs, this is the category of component that determines whether those pipelines survive deploys without dropping in-flight jobs.
• Prior-art decision, not a dependency decision. With 0 stars, 0 dependents, and no visible maintenance signal, the defensible use is as a reference implementation to inform an ADR — "we evaluated X, chose Symfony Messenger, here's the gap we're closing and how."
• Vendor-risk register. Adopting a zero-adoption MIT package means we own the fork. That's a resourcing decision (who maintains it, what's the upgrade path), not just a technical one.

When to Consider This Package

Consider it when:

• The team is on Symfony — the bundle packaging strongly implies this; it is not a Laravel fit.
• You want to read it, not require it: a compact example of daemon lifecycle handling to borrow patterns from before writing your own worker config.
• You have an existing Supervisor/systemd setup and need a thin wrapper, and someone on the team is willing to own a pinned fork with tests and a changelog.

Look elsewhere when:

• Production criticality is non-zero. Zero stars, zero dependents, no release history, no visible CI or tests means no community, no security response path, and no upgrade story. You are the maintainer from day one.
• You need the table stakes of a real queue system: retries with backoff, dead-letter queues, idempotency guarantees, observability (metrics/tracing), transport abstraction. Assume these are absent until proven otherwise — verify before it reaches a design doc.
• First-party options already cover it. Symfony Messenger (plus a mature transport) or Laravel Horizon/Queue give you the same layer with an upgrade path and a hiring pool.
• You can't commit engineering time to a fork. "Free MIT" plus "abandoned" equals an unfunded maintenance obligation.

How to Pitch It (Stakeholders)

To executives: This is a small, permissively licensed Symfony component for running background workers. Commercially it is not a dependency we should take on — zero adoption and no maintenance signal means we would be the sole maintainer of a fork, with no security or upgrade path. Its value is as prior art. It shows the shape of a worker lifecycle we can reproduce on top of Symfony Messenger in roughly a sprint, with first-party support and a real upgrade path. Recommendation: do not adopt; cite as evaluated prior art in an ADR.

To engineering: Treat it as a reference, not a dependency. Read the signal-handling and memory-limit loop and port the ideas into our Messenger worker configuration or our Supervisor/systemd policies. If we ever do adopt it, pin the commit, vendor it, add tests, document the fork owner, and set a review date. Re-evaluate only if it gains maintainers, releases, or a transport we genuinely need.