Omniterm Laravel Package

Product Decisions This Supports

• Build vs. buy for CLI experience. OmniTerm collapses what is normally a multi-sprint internal project — ANSI colour handling, layout, tables, spinners, progress bars, live redraw — into one composer require. The decision becomes "adopt a dependency and wrap it" rather than "assign an engineer to write a terminal renderer."
• Whether Artisan is a first-class product surface. If your roadmap includes operator-facing commands (deployments, data imports, backfills, health checks, tenant provisioning), this package is the argument that those commands deserve designed output rather than $this->line() soup. It gives a shared visual vocabulary — status badges, key-value tables, framed progress bars — that maps 1:1 onto a Tailwind design language the team already speaks.
• Standardising an internal CLI design system. The Blade-template path ($this->omni->view('cli.deploy-status', [...])) means terminal output can live in resources/views and be reviewed, versioned, and reused like any other UI. That supports a governance decision: one house style for all internal commands, owned by the team rather than by whoever wrote the command.
• Developer-experience investment. Status blocks with actionable help lines (statusError('Connection Failed', ..., ['Check .env', 'Ensure MySQL is running'])) turn error output into an onboarding artefact. Supports DX/onboarding roadmap items and reduces support tickets for internal tooling.
• Support and demo tooling. The interactive split-pane browser and liveTask counters lend themselves to internal dashboards, server inspectors, and pre-sales demos that run in a terminal — areas where a full web UI is overkill.
• Long-running job feedback. runTask() / liveTask() with per-row counters (created/updated/skipped/failed) is a credible substitute for bolting a progress dashboard onto a batch job. Supports the "can we skip building the admin screen for this one-off migration?" question.
• Adoption risk register entry. Low score, zero dependents, and a solo maintainer are themselves a decision input: the sensible PM output is a pilot-and-wrap decision, not a platform commitment.

When to Consider This Package

Adopt when:

• You are on Laravel 11/12/13 and PHP 8.2+ (v3.0.0 dropped Laravel 10 and Symfony 6 — check this first, it invalidates many older codebases immediately).
• You already ship Artisan commands that humans watch run: migrators, importers, seeders, sync jobs, deployment scripts, smoke tests.
• The team knows Tailwind. The class vocabulary (flex-1, text-emerald-600, bg-gradient-to-r) transfers directly, so the learning cost is near zero and code review is meaningful.
• You need truecolor, gradients, or dynamic RGB (text-[R,G,B]), or per-character colour transitions — the differentiators over the incumbent.
• You want progress bars, spinners, and live-updating counters without hand-rolling cursor-rewrite logic.
• You want an interactive list/detail browser without adopting a heavier TUI framework.
• The output is disposable or internal — the cost of a broken render is a cosmetic annoyance, not a customer incident.

Look elsewhere when:

• Laravel 10 or earlier, or PHP < 8.2. Hard blocker.
• You need only basic coloured output. Laravel Prompts, Termwind (the pioneer this builds on), and plain Symfony Console styling cover 80% of cases with far stronger adoption and first-party adjacency.
• You need battle-tested, widely-deployed, multi-maintainer dependencies. Score 1.5, zero dependents, and a single author are real signals; there is no ecosystem of Stack Overflow answers, no third-party tutorials, no community patch velocity.
• Output must be machine-parseable or CI-safe. Spinners and liveView() redraws emit cursor-control sequences that corrupt log capture and CI artefacts. Keep a --no-interaction / plain-output path regardless.
• Accessibility or screen-reader consumers are in scope. Animated redraws and colour-only status encoding are hostile to both. Pair colour with text labels if this matters.
• You are not on Laravel, or you need this in plain PHP CLI tools.
• You need a stable, contracted API. This is pre-1.0-shaped in practice (v3.0.0 was a breaking release), so treat every minor as potentially disruptive.

Decision rule: pilot on one non-critical internal command. If it survives a month without rendering surprises, expand. Do not put it on the critical path of production deploys, and wrap it behind a thin internal ConsolePresenter so swapping to Termwind or Prompts is a day's work.

How to Pitch It (Stakeholders)

To executives (one paragraph): Our Artisan commands are an unpolished but heavily used internal product surface, and we currently spend engineering time hand-formatting terminal output. OmniTerm is a free, MIT-licensed Laravel package that gives us a consistent, well-designed look for that output — progress bars, status badges, tables, spinners, and live-updating job counters — written in a styling language our team already uses for the web. The cost is a single dependency and roughly a day of integration on a pilot command; the benefit is that operator-facing tooling looks and reads like a real product, and errors tell people what to do next. The risk is maintenance: it is a young package from a single author with no downstream dependents. We mitigate that by piloting it on one internal command and isolating it behind a small internal wrapper, so removal — if it ever comes to that — is a contained change, not a rewrite.

To engineering: This removes ANSI string-wrangling from our codebase. Terminal layout becomes Blade templates with Tailwind classes, compiled to truecolor ANSI with automatic 256-colour fallback for older terminals — no config. It ships real components (status blocks, key-value tables, three progress-bar styles, ten spinner animations, async runTask, live-increment counters, a split-pane item browser, prompts) so we delete bespoke cursor-rewrite code instead of writing more of it. Caveat clearly stated: solo maintainer, zero dependents, breaking changes between majors, Laravel 11+ only. So: depend on it behind our own interface, keep a plain-output fallback for CI and non-interactive runs, and do not let it become load-bearing on the deploy path until it has proven itself.