Laravel Tactician Laravel Package

Technical Evaluation

Architecture fit

• The package is a thin Laravel service-provider wrapper around league/tactician, mapping Laravel's container to Tactician's handler locator and middleware pipeline. Conceptually it fits any Laravel app: controllers stay thin, commands/handlers encapsulate use cases, middleware handles cross-cutting concerns (transactions via DoctrineTransactionMiddleware equivalents, logging, validation).
• The CQRS-lite pattern it enables is still sound, but as of Laravel 5.5+ the framework ships an equivalent in-house capability (Illuminate\Contracts\Bus\Dispatcher, dispatch(), ShouldQueue, Bus::pipeThrough, job middleware). The package's value proposition has effectively been absorbed by the framework.
• Net: architecture fit with the pattern is high; fit with the package is low for any stack newer than Laravel 5.x.

Integration feasibility

• MIT license, Composer-installable, single config file, one interface per command — the mechanical integration is trivial where it works at all.
• The blocking constraint is version compatibility. The only release is dated 2016-04-10, which predates Laravel 5.5's package auto-discovery (Aug 2017) — so the auto-discovery claim in the description should be treated as unverified until the composer.json require block is inspected. Expect hard pins to illuminate/* 5.1–5.2 era and PHP 5.5/7.0 constraints that fail resolution against Laravel 8+ or PHP 8.x.
• The repository is archived. That is the decisive technical fact: no upstream fixes, no security response, no compatibility patches.

Technical risk

• Critical: archived + single release + 5 stars + zero release activity for ~9 years. Bus factor of one, with no successor or maintenance commitment.
• High: framework coupling to an EOL Laravel major. Adopting it pins the application's upgrade path to a fork we maintain ourselves.
• Medium: PHP 8 incompatibilities (signature/type deprecations) and any divergence from the current league/tactician API surface.
• Low: runtime performance — a command bus adds negligible overhead at typical application scale.
• The composite score (0.19) and star count are consistent with an abandoned artifact rather than a viable dependency.

Key questions

1. What exact illuminate/* and php constraints does the tagged composer.json declare, and can it resolve against our current composer.lock?
2. Is the app genuinely on Laravel 5.x, or is this being considered for a modern codebase? (If the latter, the answer is no.)
3. Does it pin an old league/tactician that conflicts with newer versions we may already depend on?
4. Is there a test suite or CI config? (Assume not until proven otherwise.)
5. What is the internal cost to fork, modernize, and own this — versus wiring the same pattern onto Laravel's native bus in 1–2 sprints?
6. Are there known security advisories against the transitive dependencies frozen at 2016 versions?

Integration Approach

Stack fit

• Fits only a Laravel 5.x application, and only as a convenience layer. For Laravel 6+ the correct answer is the framework's native command bus, optionally wrapped in our own CommandBus port to preserve the same architectural boundary.
• If the team specifically wants Tactician semantics (middleware pipeline composition, CommandBus interface, Next-style middleware), the dependency to evaluate is league/tactician directly, not this wrapper.

Migration path

• Preferred: do not adopt. Implement a small internal command bus (one interface, one container-backed handler locator, one middleware pipeline — roughly a few hundred lines) over Laravel's native dispatcher. This captures the entire product value of the package with zero abandonment risk and no framework version coupling.
• Fallback (only if already on Laravel 5.x and mid-flight): fork into a private VCS repository, relax version constraints, add a smoke test, and pin the fork. Treat this as owned internal code from day one.
• Regardless of path, place the bus behind an application-owned interface (e.g. App\Bus\CommandBus) so the implementation — package, fork, or native — is swappable via container binding.

Compatibility

• Verify PHP constraint, Laravel constraint, PHPUnit/PHP version matrix, and whether handler resolution assumes pre-Container::build() semantics.
• Check queue support: dispatching commands from queued jobs behaves differently post-Laravel 5.5; assert behavior explicitly rather than assuming it.

Sequencing

1. Spike (time-boxed, ≤2 days): attempt composer require in a throwaway branch against our actual lock file; capture resolution errors and PHP 8 fatals as evidence.
2. Decision gate: if resolution requires more than constraint relaxation, recommend the internal-adapter path and close the evaluation.
3. If forking: add CI, a test covering dispatch + middleware + container injection, and a documented deprecation plan.
4. Pilot: adopt in one non-critical module only, behind the internal interface, with a defined rollback (revert binding, keep commands as plain classes).
5. Retrofit: only promote to wider use after the pilot survives one framework minor upgrade.

Operational Impact

Maintenance

• Effectively 100% ownership transfer on adoption. Upstream is archived: no bug fixes, no compatibility work, no releases. Every future Laravel or PHP upgrade becomes our problem, in a capability that is explicitly non-differentiating.
• Ongoing tax is small in absolute hours but recurs on every framework upgrade, and lands precisely when the team is busiest (upgrade season). This is the classic "cheap dependency, expensive ownership" trade.

Support

• No community. No issue triage, no security disclosure channel, no maintainer responsiveness. Documentation is a README plus a one-line 1.0.0 changelog — no upgrade guide, no version support matrix.
• Onboarding relies on the team reading source; tolerable at ~300 lines, but it is undocumented source.

Scaling

• Application-level throughput is unaffected; the bus is in-process and cheap. Middleware pipelines remain composable if queues are used for async work.
• The real scaling constraint is organizational: the dependency cannot scale with the platform's upgrade cadence. It becomes a pin that blocks PHP major-version adoption, which in turn blocks security patching of the runtime.

Failure modes

• Silent framework breakage: handler locator or middleware pipeline semantics change on upgrade; failures surface as "no handler found" or unexecuted middleware — often at runtime, not in tests, if coverage is thin.
• PHP 8 fatals: signature incompatibilities in handler resolution produce hard errors on version bump.
• Security exposure: transitively frozen 2016-era dependencies with no patch path; cannot be remediated without forking.
• Institutional: the one person who understands the fork leaves; the bus becomes load-bearing but unowned.
• Upgrade deadlock: team defers Laravel upgrades to avoid touching the bus, accumulating framework debt across the whole product.

Ramp-up

• Low for the mechanic: publish config, define commands/handlers, dispatch. A mid-level Laravel engineer is productive in under a day.
• Moderate for the concept: CQRS-lite discipline (one handler per command, no logic in controllers, middleware ordering) requires architectural buy-in and review conventions — this is where the real cost sits, and it is identical to what the native bus requires.
• High for the fork, if that path is chosen: understanding a 2016 codebase well enough to own it safely is a multi-day investment for a single individual, with no external help available.

Recommendation for the TPM: Do not adopt. The pattern is worth keeping; this artifact is not. Capture the architectural intent (thin controllers, one handler per use case, middleware for transactions) in an ADR, implement it on Laravel's native bus behind an owned interface, and revisit only if the platform is discovered to be genuinely pinned to Laravel 5.x with no upgrade path in the next two quarters — in which case fork and own it explicitly rather than depending on an archived package.