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

Bus Laravel Package

laravelcollective/bus

A command bus for Laravel that dispatches commands to their handlers, with middleware support and container integration for cleaner, decoupled application logic.

View on GitHub
Deep Wiki
Context7

Technical Evaluation

Architecture fit. laravelcollective/bus is a standalone extraction of Laravel's command bus (dispatcher, handler resolution, middleware pipeline, queueing dispatch). Its architectural value is essentially zero on any Laravel ≥ 5.1 stack: the command bus ships in the framework core (Illuminate\Bus\Dispatcher, Illuminate\Contracts\Bus\Dispatcher, dispatch() helper, ShouldQueue and middleware), so this package would duplicate or shadow first-party classes. It only "fits" in a narrow scenario — a Laravel 4.2/5.0-era application that wants command/handler separation without upgrading the framework, or a non-Laravel consumer wiring Illuminate components manually.

Integration feasibility. Mechanically low effort (composer require, register BusServiceProvider, optionally alias the dispatcher facade) but practically fragile. In 2015-era apps, installation is a one-line dependency; in modern apps it is a dependency-conflict generator, because the package pins Illuminate/Symfony components from that period. Attempting to install it alongside Laravel 8–12 will either fail resolution or force downgrades that break the framework.

Technical risk. High and non-mitigable:

  • Archived / unmaintained since 2015-12-23 — no security patches, no PHP 8 compatibility work, no Composer 2-era constraint hygiene.
  • Runtime incompatibility — PHP 5.5/5.6-era code patterns (reflection usage, each(), untyped signatures) are deprecated or removed in PHP 7.4+/8.x.
  • Supply-chain exposure — transitive Symfony/Illuminate pins of that vintage are almost certainly flagged by composer audit, with no upgrade path short of forking.
  • Bus-factor and abandonment — 30 stars, archived repo; no upstream to escalate to.
  • Silent behavioural divergence — if mixed with framework-native bus classes, you get two dispatchers, inconsistent middleware ordering, and confusing queue semantics.

Key questions.

  1. Does any target application actually run Laravel ≤ 5.0, or is this being proposed for greenfield/modern work (in which case: reject)?
  2. If legacy, what is the cost/risk of a framework upgrade versus maintaining a frozen dependency?
  3. Is the command bus load-bearing (queued handlers, transactions, middleware) or incidental?
  4. Would a thin internal wrapper over Illuminate\Contracts\Bus\Dispatcher satisfy the need without the abandoned dependency?
  5. Who owns the fork if we vendor it, and for how long?

Recommendation: do not adopt. Treat as a legacy artifact only, and only inside an application already pinned to that era.

Integration Approach

Stack fit. Native fit only with PHP 5.5/5.6 and Illuminate ~5.0. On Laravel 5.1+ through 12, the correct integration is no package — use Illuminate\Bus, dispatch(), ShouldQueue, and bus middleware provided by the framework. On non-Laravel PHP services, prefer illuminate/bus (first-party, maintained) over this fork if a command bus is genuinely required.

Migration path. Two directions:

  • Out of the package (recommended): replace LaravelCollective\Bus\* imports with Illuminate\Bus\* / Illuminate\Contracts\Bus\*; delete the service provider registration; remove the dependency; verify handler resolution (SelfHandling vs. CommandHandler) maps to the framework's HandlerResolver; confirm queued commands still serialize identically. This is a mechanical refactor with a real test surface around queue payloads.
  • Into a maintained fork (fallback): vendor the code, add PHP 8 type/reflection fixes, replace deprecated calls, re-pin constraints, and add CI. Estimate this as ongoing ownership, not a one-off.

Compatibility. Assume incompatibility by default. Validate with composer why-not, composer audit, and a PHP 8.3 matrix run before any commitment. Pay particular attention to serialized job payloads in queues — changing dispatcher internals can orphan in-flight jobs during rollout.

Sequencing.

  1. Inventory: which modules dispatch commands; sync vs. queued; middleware in use.
  2. Decide migrate-to-core vs. fork; get an explicit engineering sign-off on ownership.
  3. Build a characterization test suite around dispatch/handler/queue behaviour.
  4. Migrate in one service/domain at a time, draining queues between cutovers.
  5. Remove the package and add a CI guard (composer audit, dependency-allowlist) to prevent reintroduction.

Operational Impact

Maintenance. Effectively infinite relative to value: archived code means every PHP/Laravel upgrade becomes a compatibility investigation with no upstream fix. Budget for fork ownership if retained; otherwise the maintenance win from removal is immediate and permanent.

Support. None. No maintainer, no security advisories, no community answers for modern versions. Internal escalation path is "whoever last touched the fork."

Scaling. The bus itself is thin — dispatch overhead is negligible; scaling is a function of the queue backend (Redis/SQS/database), not this package. Risk appears at scale in serialization compatibility and in the absence of middleware for retries, idempotency, and tracing that the modern framework bus offers.

Failure modes.

  • Dependency resolution failure at install/CI (most likely outcome on any modern stack).
  • Fatal errors or deprecation storms on PHP 7.4+/8.x.
  • Duplicate/competing dispatchers causing handlers to be skipped or invoked twice.
  • Orphaned or unserializable queue jobs during a partial migration.
  • Unpatched CVE in a transitive dependency with no remediation path.
  • Silent drift as engineers assume the bus behaves like the documented framework bus.

Ramp-up. Near-zero learning cost (the API mirrors the framework), but non-trivial context cost: engineers must be told why an archived duplicate of a core component exists, and must not pattern-match it into new code. That explanation burden is itself a reason to remove it.

Bottom line for the roadmap: classify as divest. Block new usage, schedule removal from any surviving legacy service as part of the next framework-upgrade window, and standardize on Illuminate\Contracts\Bus\Dispatcher. The only acceptable ongoing cost is a time-boxed, owner-assigned vendored fork for a legacy app with a dated exit plan.

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.
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
cgv/localized-resource