Laminas Cli Laravel Package

Product Decisions This Supports

• Build vs. buy on CLI bootstrap plumbing. This package is a thin adapter — a bin/laminas runner that reads a laminas-cli.commands config map and resolves each command through a PSR-11 container. The decision it informs is whether to hand-roll command registration/discovery or take a ~50-line dependency. For a Laminas MVC or Mezzio codebase, buying wins; there is nothing proprietary here to build.
• Ecosystem fit check (the decision that matters most). Despite being categorized as a "Laravel/PHP package," this is not Laravel tooling — it targets Laminas MVC and Mezzio. Laravel already ships Artisan (Symfony Console + container resolution + scheduling + queues) with far richer ergonomics. The PM-level call for a Laravel shop is no-go; for a Laminas/Mezzio shop it is low-cost default.
• Feature surface for operational tooling. It unlocks the standard "back-office" roadmap items without new infrastructure: backfill and data-migration scripts, cache/index warmers, scheduled cron entrypoints, import/export jobs, and one-off runbook commands — all executing inside the same DI container as the web app, so credentials, config, and service wiring are reused rather than duplicated in shell scripts.
• Packaging and reuse strategy. Because commands are just classes registered via config, a platform team can publish internal command packages (e.g., acme/ops-commands) and register them in every Laminas/Mezzio app with one config entry and factory mapping. That supports a "shared internal tooling library" roadmap item cheaply.
• Migration scoping. If a Laminas→Laravel migration is on the roadmap, this package is an inventory marker: every configured command key and factory is a unit of work to port to an Artisan command. Counting them gives a defensible estimate for the CLI slice of migration effort.
• Risk posture for procurement/security review. BSD-3-Clause, no runtime services, no data egress. The real risk signal is adoption: ~56 stars, 0 dependents, and a release history dominated by PHP/Symfony version-support bumps rather than features (1.13 drops PHP 8.1 / adds 8.5; 1.14 permits Symfony v8 and drops v6; 1.15 adds Symfony Console attribute support). Treat it as maintenance-mode infrastructure glue, not a strategic bet.

When to Consider This Package

Adopt when all of these hold:

• The application is Laminas MVC or Mezzio (or a shared library that must serve both).
• A PSR-11 container is already in place (laminas-servicemanager or equivalent), so command dependencies can be injected rather than constructed.
• You are on PHP 8.2+ and symfony/console ^7 or ^8 — the supported window is narrow and moves with each minor release.
• You want config-driven registration and/or Symfony Console attributes (1.15+) instead of a bespoke console entrypoint.
• You need a --container=<path> escape hatch to boot an alternate container (useful for CI, cron, or multi-tenant deployments).

Look elsewhere when:

• You are on Laravel. Use Artisan. Adding this creates a parallel, redundant command runner with no scheduler, no queue integration, and no ecosystem support.
• You are on full-stack Symfony. symfony/framework-bundle's console application already does container-backed command discovery; this adds a duplicate abstraction.
• You need more than a runner. No scheduling (pair with cron/Supervisor or a dedicated scheduler), no queueing, no REPL, no output/theming layer beyond what Symfony Console gives you.
• Bus factor is a gating concern. Single-maintainer-dominated commit history and near-zero dependent count mean you should expect to vendor or fork it if it goes stale — acceptable for glue code, unacceptable for anything load-bearing.
• The team has no Laminas/Mezzio familiarity. Onboarding cost exceeds the value of the package itself.

How to Pitch It (Stakeholders)

To executives: This is small, free (BSD-3), and boring in the right way — a connector that lets our existing Laminas/Mezzio applications expose operational commands (data fixes, imports, warmers, cron jobs) through one consistent entrypoint instead of scattered shell scripts. It removes duplicated credentials and config from ops scripts and gives us a reusable internal tooling library across apps. The honest caveat: it is niche, low-adoption glue with a thin maintainer base, so we adopt it only where we already run Laminas/Mezzio — and if our stack is Laravel, we should not adopt it at all, because Laravel's Artisan already covers this and more. Cost is roughly a day of engineering to register our first commands; ongoing cost is a Composer bump per PHP/Symfony major.

To engineering: One composer require, one laminas-cli.commands config key mapping vendor:command names to command classes, and a factory per command in service_manager (MVC) or dependencies (Mezzio). Commands are plain symfony/console commands, so they're portable and testable in isolation; since 1.15 you can use Console attributes instead of the config map. Constraints to plan around: pinned to PHP 8.2+ and symfony/console 7–8, no scheduling layer (we own cron/Supervisor), and it is a runner only — do not let it grow into a home for business logic. Treat it as replaceable infrastructure: keep command classes free of package-specific APIs so a future move to Artisan or a standalone Symfony console app is a mechanical port, not a rewrite.