Laravel Prompts gives PHP command line apps browser-like input

A prompt package for PHP, not a Laravel extension

The most useful thing about Laravel Prompts is where its boundary sits. It is a PHP package for adding forms to command line applications, and the project states that while it is aimed at accepting user input in Artisan console commands, it may also be used in any command-line PHP project. Nothing in the package description ties it to the framework.

That matters for a specific kind of team. A codebase that has one Artisan command and six standalone scripts that run from cron has two options: write the input handling twice, or have one layer that works in both places. This package is built to be that layer, and it does it without requiring the framework to be bootstrapped.

The other half of the positioning is the comparison the project draws with the browser. The features it lists are browser-like ones, and the two it names are placeholder text and validation. That is the whole promise in one sentence: the field the user sees behaves like an input in a web form rather than like a bare question followed by a line of typing.

The package is distributed under the MIT licence, with the licence text in `LICENSE.md` at the repository root, so there is no copyleft obligation and no per-seat fee for using it in a commercial product.

Placeholder text and validation are the two named features

Placeholder text and validation are the two capabilities the introduction names, and they are worth separating because they solve different problems.

Placeholder text tells the user what shape of answer is expected before they type anything. Without it, a console command that asks for a deployment target looks identical whether it wants a hostname, a region code or a yes-or-no answer. With it, the expected format is visible at the moment of the question.

Validation is the part that changes the behaviour of the program. A prompt that validates can refuse an answer that does not fit and ask again, rather than accepting whatever was typed and failing later, in the middle of a long command, with the user several steps further from the mistake.

What the package does not do is listed in the repository rather than promised in it. There is no `docs/` directory. The source is in `src/`, the tests are in `tests/` with a `phpunit.xml` configuration file, static analysis is configured through `phpstan.neon.dist`, and there is a `playground/` directory that is presumably where you can exercise the prompts without wiring them into an application. The `art/` directory holds the logo assets, and `CHANGELOG.md` sits next to `composer.json` at the root.

So the source is well organised for a package, and the documentation is deliberately hosted elsewhere.

Documentation lives on laravel.com, not in the repository

The project points to the Laravel website for its documentation, at the prompts page under the main Laravel documentation, and the README itself carries almost nothing beyond the introduction and the project links. There is no usage example in the README, no API listing and no configuration file in the repository.

For a package aimed at teams, that has two sides. The upside is a single maintained source of truth for the documentation, written for the Laravel ecosystem as a whole rather than for one repository. The downside is that the code and the prose are versioned separately, so a pinned `laravel/prompts` version and the documentation page you read may not describe the same release.

The repository does include the surrounding project furniture. There is a code of conduct referenced for the Laravel community, a contributing guide pointing at the Laravel documentation, and a link to the GitHub security policy describing how to report vulnerabilities. That is the standard shape for a package maintained inside a larger organisation: the process lives in the organisation's documentation, the code lives in the repository.

The MIT licence is declared in both the README and the `composer.json` metadata, which is the usual place to look when you need to know what a dependency requires of you.

A 0.3.x version line means the API can still move

The release numbers tell you more about adoption risk than the README does. The recent tags are v0.3.24 on 2026-08-25, v0.3.25 on 2026-10-06 and v0.3.26 on 2026-10-13, and the repository is not archived, with the last push on 2026-10-14. So the work is active and the patch releases are frequent.

That frequency is the point of interest. A package that ships a new patch roughly every week is one where behaviour is still being adjusted in response to real use, and the version number says so plainly. Under semantic versioning, a 0.x release carries no stability promise at all, so a 0.3.26 to 0.4.0 jump can break call sites that a 1.0 to 2.0 jump would not.

For a command line input library, that risk is contained. The surface is small, the functionality is user facing rather than data facing, and a breaking change shows up as a prompt that renders differently or a validation rule that behaves differently. It does not corrupt anything. The mitigation is mundane: pin the version in your `composer.json` and read the `CHANGELOG.md` before bumping.

The activity itself is a point in the project's favour. The gap between the last push on 2026-10-14 and the newest release on 2026-10-13 is one day, so releases are following the commits closely rather than lagging behind them.

The alternative is hand-written readline handling

The obvious alternative is to keep doing what most PHP console scripts do now: read from standard input with a small helper, print a question, cast the answer to an integer or a string, and check the result afterwards. Every project that needs a name, a path or a yes-or-no choice ends up with a slightly different version of that loop.

The difference in approach is not that the package does something clever. It is that the affordances move from your command into a reusable layer. Placeholder text is a piece of markup you would otherwise write once per prompt, and validation is a rule you would otherwise write per command, usually after the first time a user typed something unexpected. Centralising that is the whole value, and it is a modest amount of code that you would write yourself anyway.

The counter-argument is real too. A package you did not write is a dependency with its own release cadence, its own documentation on another site and a version number that promises nothing. For a project with two prompts in it, the maintenance arithmetic may not pay for itself. For a project with a dozen commands that all need validated input, it very likely does.

The deciding factor is not the feature list but where your input handling already lives. If it is scattered across command classes, this package has something to consolidate. If it is already in one helper function of yours, there is less to gain.

Editorial conclusion

Laravel Prompts fits a PHP developer writing a console command that needs to ask for a name, a path or a choice and wants the input to behave like a form instead of a bare prompt, and it fits teams that want one input layer shared between Artisan commands and standalone scripts. It does not fit a project that has to stay on a stable API, because the package is still published under a 0.3.x version, and it does not fit a non-PHP command line tool. Check three things before you adopt it: that your command actually needs structured input rather than a flag, that the version you pin does not move under you because the newest release, v0.3.26, came on 2026-10-13 while the last push was on 2026-10-14, and that the API you need is documented, since the repository ships no documentation directory and everything points to the Laravel documentation site.

Frequently asked questions

Official sources

1. laravel/prompts on GitHub
2. License: MIT
3. Project website
4. README
5. Releases