Laravel Command File Picker Laravel Package

Product Decisions This Supports

• Developer-experience (DX) roadmap for internal tooling. The package is a UX primitive, not infrastructure: it turns a free-text argument (class name, file path) into a guided, discoverable selection inside an Artisan command. That maps directly to decisions about how much we invest in first-party scaffolding and CLI ergonomics.
• Build vs. buy for code-generation and scaffolding commands. If our roadmap includes custom make:*-style generators, refactor helpers, or admin CLI wizards that operate on existing models/classes, this is a reference implementation of the "pick from discovered classes" interaction. The honest comparison is not "this package vs. nothing" but "this package vs. ~30 lines on top of Laravel Prompts."
• Feature scoping for interactive commands. Supports deciding whether an internal command should accept a required argument (CI-friendly, scriptable) or offer an interactive picker (human-friendly, lower error rate). Best pattern is both: argument for automation, picker as fallback.
• Onboarding and support-tooling bets. A picker that lists real classes/files lowers the knowledge barrier for new engineers running maintenance commands — a small but measurable reduction in "which model do I pass?" Slack questions.
• Dependency governance policy. With 10 stars, 0 dependents, and a last release in December 2020, this is a data point for the broader decision of how we treat unmaintained single-maintainer packages — even low-risk ones.
• Use cases that fit well: interactive selectors in code generators, model/migration/test-fixture pickers, local-only admin utilities, and CLI wizards for repetitive refactors.

When to Consider This Package

Consider it when:

• The application is pinned to a Laravel version that predates first-party prompt helpers (Laravel Prompts shipped in the Laravel 10/11 era), and upgrading the framework is not on the near-term roadmap.
• You specifically want class/file discovery plus selection in one call — scanning app/ for classes and presenting them — and want to avoid writing and maintaining the glob/reflection/namespace-mapping glue yourself.
• The command is internal developer tooling with a small blast radius: it runs on developer machines or CI, never in the production request path, so a stale dependency cannot become a runtime or security incident.
• You need a working reference implementation quickly and are comfortable forking it. At this size, "vendoring the pattern" is a legitimate outcome.

Look elsewhere when:

• You are on Laravel 10+ — use the framework's native select/search/suggest prompts. They are maintained by the core team, support fuzzy search, multi-select, validation, and custom theming, none of which this package offers.
• Your dependency policy forbids unmaintained packages, or requires an active security-response path. Zero dependents means zero community validation; the support burden transfers entirely to us.
• You need multi-select, searchable/filterable lists, confirmation flows, or non-CLI (web/admin panel) selection — this package does not cover those, and stretching it there is a build, not a buy.
• Compatibility with current PHP/Laravel versions is unverified. Last release 2020 means we should assume we will be the ones fixing it.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a tiny, MIT-licensed developer-experience utility that makes internal Laravel commands friendlier by letting engineers pick a file or class from a list instead of typing it from memory. It carries no production runtime risk and no licensing cost, but it also carries no strategic value and is effectively unmaintained since 2020. My recommendation is not to adopt it as a dependency: the capability is now built into modern Laravel, and the remaining value is as a design reference we can reimplement in an afternoon. Treat it as a pattern to copy, not a line item to budget.

For engineering (the actual ask): Do not add this to composer.json. Instead, take the interaction model — discover candidate classes/files, present a searchable select, fall back to an explicit argument for CI — and implement it with Laravel Prompts. Roughly a day of work including tests, versus an unmaintained transitive dependency we would own forever. If we are stuck on an older Laravel line, fork the package into our own namespace rather than depending on the upstream tag, and pin it explicitly.

Decision framing to state out loud: the cost of building here is near-zero and the cost of owning a stale dependency is nonzero and permanent. That asymmetry, not the star count, is the reason to decline adoption.