Bus Laravel Package

Product Decisions This Supports

• Build vs. buy vs. use the framework default. This package answers a single question — "should we introduce a command bus abstraction?" — and its answer is now "use what Laravel already ships." The decision it best supports today is retire the dependency, not adopt one.
• Architecture standardization. A command bus gives you one consistent path from HTTP/queue entrypoints to domain handlers, plus middleware for transactions, validation, and logging. That is a legitimate product-engineering decision (predictable onboarding, easier auditing of side effects), but it no longer requires a third-party package.
• Technical-debt triage and upgrade planning. If this appears in a composer.json, treat it as a blocker finding: it pins the product to the Laravel 5.1/5.2 era and prevents upgrades to any supported PHP or Laravel version. That feeds directly into roadmap sequencing (upgrade work vs. feature work) and support-cost estimates.
• Maintenance-budget conversations. Archived + last release 2015-12-23 + 30 stars means zero upstream fixes, no security patching, and no vendor to escalate to. Useful evidence when justifying spend on modernization.
• Historical/legacy scoping only. Reasonable for auditing an inherited codebase or estimating migration effort on an old product — not for greenfield use cases.

When to Consider This Package

Adopt only if all of the following are true (in practice: never for new work):

• You are maintaining an existing application already pinned to Laravel 5.1/5.2 and PHP 5.x, and you need a stopgap before a planned upgrade.
• You cannot yet migrate to native Illuminate\Bus / dispatchable jobs, and a rewrite of the dispatch path is out of scope for the current quarter.
• You accept that you own the code: fork it, vendor it, and audit it, because upstream will never ship a fix.

Look elsewhere — or don't use a package at all — when any of these hold:

• Modern Laravel (5.5+ through 11/12): the framework's built-in bus, dispatch(), queued jobs, pipelines, and events cover the same ground with no dependency.
• You need PHP 8 support, PSR-compatible DI, or auto-discovery: this package predates all of it.
• You need durability, retries, or async at scale: use the queue + jobs layer, or a dedicated message bus (Symfony Messenger, Laravel Horizon for operational visibility).
• Security or compliance review is in the loop: an archived 2015 package with 30 stars will not survive it, and shouldn't.

How to Pitch It (Stakeholders)

For executives: This is an unmaintained, decade-old library that solves a problem Laravel now solves natively. It carries support and security risk with no upside. Recommendation: do not adopt; if it's already in the codebase, budget a small, well-scoped removal as part of the next framework upgrade — this is cleanup, not a product initiative.

For engineering: laravelcollective/bus is the community continuation of the Laravel 5.1 command bus, archived since December 2015 and last released 2015-12-23. It has no PHP 7/8 compatibility, no package auto-discovery, and no maintenance path. The capability it provides — command-to-handler dispatch with middleware for transactions, validation, and logging — is available in core via Illuminate\Bus, dispatchable jobs, and pipelines. Treat the dependency as a migration item: map each command/handler pair, replace dispatch calls with native dispatch() or explicit service classes, and delete the package. If the team wants the command-bus pattern as a convention, document it as an internal standard rather than a dependency — that preserves the architectural benefit and removes the supply-chain risk.