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

Tactician Bundle Laravel Package

micro-module/tactician-bundle

MicroModule TacticianBundle integrates the Tactician command bus into Symfony applications, helping you configure commands, handlers, and middleware with less boilerplate and structure command-driven business logic cleanly.

View on GitHub
Deep Wiki
Context7

Technical Evaluation

Architecture fit — the premise needs correcting. Despite being framed as a Laravel package, micro-module/tactician-bundle is a Symfony bundle, not a Laravel package. It integrates league/tactician (a command-bus library) into Symfony's DI container via a bundle class, a compiler pass for handler/tag discovery, and a configuration tree. None of those extension points exist in Laravel's container. In a Symfony application it is architecturally idiomatic — commands, handlers, and middleware compose cleanly with autowiring and service tags. In a Laravel application it is a category mismatch: Laravel already ships a first-class command bus (Illuminate\Bus, dispatch(), pipelines, queue integration), and shimming Symfony's compiled container into Laravel to run this bundle would cost more than the pattern is worth.

Integration feasibility. Low-to-moderate, and entirely dependent on framework. On Symfony: composer require, register the bundle, define middleware in config, tag handlers — a half-day spike for a developer who knows the framework. On Laravel: not feasible without a bespoke adapter layer; treat as a no-go. Independent of framework, the feasibility question is provenance: 0 stars, 0 dependents, and a repository name that reads as a personal fork of the now-archived league/tactician-bundle. That means no downstream validation, no third-party integration reports, and no evidence anyone has run this against a current PHP/Symfony matrix.

Technical risk. High, concentrated in three areas. (1) Abandonment — the upstream Tactician ecosystem is in maintenance mode, and Symfony Messenger is the supported successor; adopting this means adopting a dead-end pattern with a single unexplained maintainer. (2) Version drift — the critical unknown is whether the fork's Composer constraints support PHP 8.2/8.3 and Symfony 6/7; a fork typically exists precisely because the original did not, so verify rather than assume. (3) Silent failure surface — command buses fail quietly when a handler tag is missed or middleware order is wrong, and a low-traffic fork means those edge cases are unwritten. MIT licensing is clean, but a fork carries attribution obligations worth a two-minute diff against upstream.

Key questions to put to the maintainer or resolve in a spike.

  • What is the delta from league/tactician-bundle, and why does this fork exist — PHP 8 support, Symfony 6/7 support, or something else?
  • Which PHP and Symfony versions are in the CI matrix, and is CI green today?
  • Is there a security contact or advisory process, or is this effectively unmaintained?
  • Does it support async/queued command execution, or is it synchronous-only?
  • What is the intended consumer — is this published for internal use and simply visible on Packagist?

Integration Approach

Stack fit. Symfony only. If the target application is Laravel, stop here and use Laravel's native bus: it provides command/handler separation, middleware pipelines, queued dispatch, and first-class testing helpers with zero new dependencies. If the target is Symfony, the honest comparison is Symfony Messenger, which is the maintained, framework-native answer to the same problem and includes transports, retries, and failure queues that Tactician does not.

Migration path. Two viable scenarios, and only one is attractive.

  • Already on league/tactician-bundle, blocked on modern PHP/Symfony — this fork may be the cheapest unblock. Diff the two packages, confirm the compiler pass and middleware wiring are unchanged, and run the existing handler test suite against it. If the diff is small and CI is green, a pinned adoption is defensible.
  • Greenfield or currently on Messenger — do not migrate. Moving to an unmaintained bus to gain nothing is a net-negative trade.

Compatibility checks to run before any commitment. Composer constraints against your PHP/Symfony matrix; PSR-11 container compatibility; autowiring behaviour for handlers; that handler tags resolve under the compiled container in prod mode (not just dev); and that middleware ordering matches the documented sequence for transaction and locking middleware.

Sequencing. (1) Read the source and diff against upstream — it is a few hundred lines, this is hours not days. (2) Spike in a throwaway branch against the real app skeleton, not a toy. (3) Wrap the bus behind a thin application-owned interface (CommandBus port) so handlers dispatch through your abstraction, not the bundle's service ID. (4) Pin the exact version in composer.json and vendor the source if adoption proceeds. (5) Only then wire it into production code paths. Step 3 is the important one: it converts a dependency decision into a reversible one.

Operational Impact

Maintenance. Assume you are the maintainer. With 0 stars and 0 dependents, there is no plausible community to absorb upgrades, PHP minor-version fixes, or Symfony deprecation churn. Budget for an internal fork, or vendor the package and own the patch queue. This is a real, recurring cost, not a one-time adoption tax.

Support. No SLA, no triage cadence, no evidence of an issue-response history. Escalation path is "the one person who forked it," which is not an escalation path. Any production incident traced to the bus is yours to diagnose from source.

Scaling. The bundle is in-process. Handler invocation is synchronous unless you build queue integration yourself — Tactician has no transport, retry, or dead-letter concept comparable to Messenger. For request-scoped commands this is fine; for anything long-running or throughput-sensitive you would be writing the async layer, at which point Messenger's cost advantage disappears entirely.

Failure modes to anticipate. Missing handler tag producing an unresolvable-command error at runtime rather than compile time; middleware misordering silently dropping transaction or lock guarantees; container compile failures surfacing only under cache:warmup in prod; and composer update breaking on an abandoned transitive constraint with no upstream fix forthcoming.

Ramp-up. Low cognitive cost — command, handler, middleware is a simple mental model, and Symfony developers will recognise the bundle conventions immediately. The undocumented part is the fork's deviations from upstream, which is exactly the knowledge that no longer exists anywhere but the source. Expect half a day for a competent Symfony developer, plus whatever time the diff review takes.

Bottom line for the roadmap. This is not a package to adopt on merit; it is a package to adopt only as a tactical unblock for an existing Tactician deployment that modern PHP or Symfony has stranded. Outside that narrow case — and certainly inside a Laravel codebase — the correct recommendation is Messenger on Symfony or the native bus on Laravel, both of which are maintained, transport-capable, and supported.

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.
socialdept/tenant-domains
tautvydasr/blade-class-names
socialdept/color-scales
maherelgamil/controller
coleus/widgets
coleus/table
coleus/users
coleus/music
coleus/health
coleus/calendar
coleus/notes
coleus/support
coleus/settings
coleus/apps
seampact/laravel
emmyconceptng/laravel-ng-postcode
jjsquady/round-robin
skyraptor/chatter
edlugz/sasapay
abbasudo/artisan-route