Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Worker Bundle Laravel Package

fm/worker-bundle

fm/worker-bundle adds a structured worker layer to PHP applications, helping you organize, run, and monitor background jobs with less boilerplate. It integrates cleanly with existing frameworks and keeps long-running tasks reliable and maintainable.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Build vs. buy for background job processing. The package defines the "worker orchestration" slot on the roadmap — the layer that runs long-lived processes outside the request cycle. Evaluating it forces the question every roadmap needs an answer to: do we own this infrastructure, adopt a library, or lean on the framework's native queue? For a Laravel-first product, the answer is already the native queue (with Horizon/Supervisor), so this package's real value is as a documented "considered and rejected" entry.
  • Closing the evaluation cleanly. With zero stars, zero dependents, a score of 0, and an upstream notice that it is superseded, the PM decision is a clean "no" for new work. That is a legitimate and valuable roadmap artifact: it prevents re-litigating the same option next quarter and keeps the dependency registry honest.
  • Dependency-risk triage and SBOM policy. A package with no dependents and no maintainer activity is effectively unpatchable — any security or PHP-version incompatibility becomes our cost in a vendored fork. This feeds directly into our third-party dependency policy and annual dependency-renewal review.
  • Framework-fit gating. Despite the framing, fm/worker-bundle is a Symfony bundle, not a Laravel package. It informs nothing about our Laravel roadmap unless we operate Symfony services; the correct comparison set is Laravel's queue + Horizon or a managed queue (SQS, Redis-backed, Cloud Tasks).
  • Successor-package tracking. The description names treehouselabs/worker-bundle as the replacement. That redirect is the actionable output: if any team has fm/worker-bundle in a composer.lock, we now have a named migration target and an owner to assign.

When to Consider This Package

Consider it only in these narrow cases:

  • A legacy Symfony service already declares it as a dependency, and you need to understand what it does before replacing it.
  • You are doing architectural archaeology on an inherited codebase and want to know whether a worker abstraction was deliberate or accreted.

Look elsewhere — and specifically do not adopt — when any of the following hold:

  • Greenfield work of any kind. Superseded + zero dependents + score 0 means no community testing, no issue triage, no PHP-version upkeep.
  • You are on Laravel. Use the native queue with Horizon, or a managed queue. A Symfony bundle is not a candidate without a hand-written bridge we would own forever.
  • You need vendor support, an SLA, or a security-response path. None exists here.
  • You are on modern Symfony. Prefer Symfony Messenger, which is first-party and maintained.
  • You require long-term ownership. Prefer the named successor, treehouselabs/worker-bundle, and only after it independently passes the same maintenance and dependents check — succession does not automatically confer health.

Adoption criteria, if you must evaluate it at all: it is already in production, migration cost exceeds a rewrite, and you accept owning the fork indefinitely with a named internal owner and a date.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated fm/worker-bundle for background job processing and recommend against adoption. The package is explicitly marked as superseded by its own maintainers, has no downstream users, no community traction, and no visible maintenance — meaning any bug or security issue becomes an internal cost with no upstream fix. It is also a Symfony bundle, so it does not fit our Laravel stack. Cost of adoption is high; expected benefit is near zero. Recommendation: close the evaluation, standardize on the framework's native queue plus a managed queue service, and revisit the named successor only if a concrete requirement appears. The one open action is a quick audit for existing composer.lock references and a migration ticket if any are found.

To engineering (short): Not a candidate. Superseded upstream, zero dependents, Symfony-only. If it appears in any lockfile, plan the move to treehouselabs/worker-bundle or, preferably, Symfony Messenger / Laravel's native queue. Treat any current usage as technical debt with an owner and a remediation date, and watch for hidden transitive Symfony downgrades if a spike is ever attempted.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
pharaonic/laravel-notification-dependencies
beautinow/translug
dev-brainiac/bot-cloaked
octoberrain/html
octoberrain/extension
octoberrain/exception
octoberrain/contracts
frankyso/ipaymu
3mdikram/worldmoneywords
snowsoft/config
itmosoft/laravel-subscriptions
larva/laravel-ai-qwen
adachsoft/api-version-bundle
cgv/localized-resource
noith/settings
kda/laravel-package
kda/filament-dynamic-navigation
bypersoft/signbox
pairus/product-data
fayne/laravel-filament-cms-core