Prompts Laravel Package

Product Decisions This Supports

• CLI onboarding and installer flows. Turns "read the docs and edit .env" into a guided, validated setup wizard (make:install, first-run configuration, credential entry, environment selection). This is a direct lever on activation and support-ticket volume for self-hosted/on-prem products.
• Developer experience as a roadmap item. Replacing raw Symfony Question/$this->ask() with select, search, multiselect, suggest, confirm, hints, placeholders, and inline validation makes "polish the CLI" a small, shippable ticket instead of a project. Useful when scoring DX work that has no direct revenue line.
• Build vs. buy for interactive input. For any Laravel or plain-PHP CLI, this is a clear buy/adopt: MIT, first-party Laravel, already bundled in Laravel apps, and the hard part (terminal rendering, keybindings, multibyte handling, stty/tput fallbacks) is solved. Engineering time should go into which questions to ask and what validation rules apply — not into escape codes.
• Feature scoping for setup/maintenance surfaces. Multi-step forms with conditional steps support branching flows (e.g., "S3 or local disk?" → different follow-up questions). This lets you scope a real setup wizard in days, and lets you decide deliberately between CLI wizard vs. web setup UI rather than defaulting to one.
• Operational tooling. Spinners, progress bars, tables, and grids for long-running tasks (imports, migrations, backfills, indexing) — reduces perceived latency and makes internal tools feel finished without a frontend.
• Testability of interactive flows. Prompt fakes/expectations mean interactive commands can be asserted in the test suite. This is the gating question for whether interactive CLI can be shipped with the same quality bar as HTTP features.
• Roadmap signal. Frequent, incremental releases (grid component, number prompt, conditional form steps, PHP 8.4 / Laravel 12 compatibility) indicate an actively maintained, low-risk dependency whose capability set is still expanding — worth re-checking when scoping CLI features.

When to Consider This Package

Adopt when:

• The product ships a Laravel or standalone PHP CLI and needs human-in-the-loop input (setup, config, confirmations, data entry).
• You want validated, styled prompts with low maintenance burden and no vendor negotiation (MIT, first-party).
• You are already on Laravel — the package is effectively present via the framework, so marginal adoption cost is near zero.
• You need form-style multi-step flows with conditional branching and test coverage for those flows.

Look elsewhere or push back when:

• Non-interactive contexts dominate. CI, cron, Docker builds, and piped input must not block on a prompt. Any adoption requires a parallel flag/env/config path for every question. The changelog's repeated work on non-interactive mode and fallback prioritization confirms this is a real operational concern, not a theoretical one.
• You need a full TUI — panes, mouse support, rich layouts, dashboards. This is a prompt library, not a terminal UI framework.
• Accessibility or localization is a hard requirement. Terminal prompts are not screen-reader friendly and multilingual prompt text/layout is not a first-class concern here; a web setup flow is the better answer.
• Terminal capability is unknown or hostile. Windows shells, minimal containers, and odd TERM values are handled with fallbacks but remain the main source of field bugs. If your users run constrained environments, budget for testing there.
• The input should not be interactive at all. If the right answer is "read from a config file, flags, or an API," prompts add friction.
• Version stability is mandatory. The package is still 0.x; pin it and read changelogs before upgrades. Its low star count and "0 dependents" reflect that it is consumed as a transitive framework dependency, not a destination repo — judge it on release cadence and compatibility (PHP 8.4, Laravel 12) rather than popularity metrics.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed, first-party Laravel package we already have access to. It converts fragile "follow the setup docs" instructions into a guided, validated terminal wizard — fewer failed installs, fewer support tickets, faster time-to-first-value for self-hosted customers. No new vendor, no procurement, no licensing cost, minimal code surface. The risk is contained: it is a presentation layer over input we already collect.

To engineering: Drop-in helpers with placeholder text, hints, validation, select/search/multiselect/suggest, multi-step forms (including conditional steps), plus progress bars, spinners, tables, and grids. It is testable via prompt fakes, so interactive commands can be covered in CI. It supports PHP 8.4 and Laravel 12, and since 0.3.0 it no longer depends on illuminate/collections, so it also works in standalone PHP CLI tools. Two asks: (1) every prompt must have a non-interactive equivalent — a flag, env var, or config value — so CI and automation never block; (2) pin the version and review the changelog on upgrade, since it is still pre-1.0.