- Is sala/console a Laravel package I can require in my Laravel app?
- Despite declaring illuminate/* ^10|^11|^12 constraints, sala/console is the console layer of the salaab/framework boilerplate rather than a true Laravel package. It boots Eloquent manually on top of Symfony Console 7, Phinx and PsySH instead of going through Laravel's container, service providers or Artisan kernel. Inside a Laravel application it is architecturally redundant at best and actively conflicting at worst. Treat it as a CLI toolkit for Sala-derived projects or non-Laravel PHP apps that want Artisan-shaped ergonomics.
- What PHP version does sala/console require?
- It requires PHP ^8.4, which alone disqualifies most production estates today. The constraint set is also internally odd, because illuminate/* ^10 does not officially support PHP 8.4, so that corner of the support matrix is effectively untested upstream. If you are pinned to 8.2 or 8.3, ask the maintainers what actually requires 8.4 before planning any adoption.
- How does sala/console handle migrations alongside Laravel's migrator?
- It ships Phinx rather than Laravel's migrator, and Phinx keeps its own bookkeeping table separate from Laravel's migrations table. Running two migration engines against one database is a well-understood path to divergent schema state and unrecoverable rollbacks. Decide which binary owns migrations before writing a single line, and look for a documented do-not-run-both position from the maintainers.
- Why do sala/console commands collide with Artisan command names?
- Nineteen of its twenty commands overlap by name with Artisan, including serve, migrate, rollback, db:*, make:*, tinker, config:publish and stub:publish. In a Laravel project that means two binaries claiming the same verbs with different implementations and different config sources. Keep it as a sidecar binary outside the application, or do not install it in an Artisan-based project at all.
- How do I install sala/console and what is the upgrade story?
- Install it with Composer, but understand the binary first: copying bin/console into a consumer project root is a fork-on-install pattern, so the copy drifts from the package and upgrades become manual merges. Standalone or global usage, or vendor/bin/console inside a Sala project, is low friction and well scoped. Ask whether root-copy is a supported long-term path or a stopgap pending a proper vendor binary.
- Does sala/console support Laravel 10, 11 and 12?
- The illuminate/* constraint spans ^10, ^11 and ^12, but that is a dependency constraint, not evidence of Artisan integration or tested compatibility. Laravel 10 does not officially support PHP 8.4 either, so that combination is untested upstream as well. Validate the exact matrix you need yourself rather than assuming the constraint implies support.
- How does sala/console load configuration and .env files?
- bin/console auto-detects the project root and loads .env and config/*.php on its own terms, in parallel with Laravel's bootstrap. Inside a Laravel app that gives you two config loaders, two .env resolutions and two database connection definitions. Establish which is the source of truth for database configuration, config/database.php or config/console.php, before debugging connection problems.
- Is the PsySH history written to storage/psysh a security concern?
- PsySH writes REPL history to storage/psysh, and REPL history routinely captures credentials and customer rows. storage/ is a directory teams habitually commit, sync or ship inside build artefacts. Treat that history file as sensitive data and exclude it from version control and build pipelines.
- Is sala/console production ready and who maintains it?
- It is v1.0.0, an initial release, with a narrow dependency chain on Phinx 0.16, PsySH 0.12 and Symfony Console 7, each of which constrains upgrade timing independently. The license is not stated in the repository, and it is unclear whether salaab is a single maintainer or a team. Confirm both before you depend on it for anything long-lived.
- When should I use sala/console instead of Artisan?
- Use it as a CLI toolkit for Sala-boilerplate projects, where config/console.php, storage/psysh and the stub layout are already the established conventions. It also fits greenfield non-Laravel PHP services that want Artisan-shaped generators, output helpers and a REPL without adopting Laravel. It does not fit a Laravel application that already uses Artisan, and it does not fit any environment pinned below PHP 8.4.