Console Laravel Package

Technical Evaluation

Architecture fit — conditional, and not what the framing implies. Despite the illuminate/* ^10|^11|^12 constraint, sala/console is not a Laravel package. It is the console layer of a bespoke boilerplate (salaab/framework) built on Symfony Console 7 + Phinx + PsySH, with Eloquent bootstrapped manually rather than through Laravel's container, service providers, or Artisan kernel. In a Laravel application it is architecturally redundant at best and actively conflicting at worst. Its natural home is a Sala-derived project, or a non-Laravel PHP app that wants Artisan-shaped ergonomics.

The collision problem is the headline risk. Nineteen of the twenty commands overlap by name with Artisan: serve, migrate, rollback, db:*, make:*, tinker, config:publish, stub:publish. Two migration engines (Phinx vs. Laravel's migrator) with separate bookkeeping tables against one database is a well-understood path to divergent schema state and unrecoverable rollbacks. Any integration story must answer "which binary owns migrations" before a single line is written.

Integration feasibility — feasible as a sidecar, dubious as an in-app dependency.

• Standalone/global usage or vendor/bin/console in a Sala project: low friction, well-scoped.
• Inside a Laravel app: high friction. bin/console auto-detects project root and loads .env and config/*.php on its own terms, parallel to Laravel's bootstrap. Two config loaders, two .env resolutions, two DB connection definitions.
• bin/console copied into the consumer project root is a fork-on-install pattern — the copy drifts from the package and upgrades become manual merges.

Technical risk — concentrated in a few specific places.

• PHP ^8.4 floor. This alone disqualifies most production estates today. The constraint set is also internally odd: illuminate/* ^10 does not officially support PHP 8.4, so that corner of the matrix is effectively untested by upstream.
• Eloquent without a container. Manual bootstrap means no service provider resolution, no model event wiring beyond what's hand-rolled, no package-discovered integrations. Behavior will diverge subtly from the same model under Artisan.
• Phinx 0.16 + PsySH 0.12 + Symfony Console 7 is a three-way coupling on pre-1.0-era or fast-moving dependencies; each constrains upgrade timing independently.
• PsySH history written to storage/psysh raises a data-handling question — REPL history routinely captures credentials and customer rows, and storage/ is a directory teams habitually commit, sync, or ship in build artifacts.

Key questions for the maintainers:

1. Is sala/console intended for Laravel applications at all, or exclusively Sala derivatives? The illuminate/* constraint suggests the latter is being read as the former.
2. Can the PHP floor be relaxed to ^8.2 or ^8.3? What actually requires 8.4?
3. How does Phinx's phinxlog table coexist with Laravel's migrations table? Is there a documented "do not run both" position?
4. Where does DB configuration come from when run inside a Laravel app — config/database.php or config/console.php?
5. What is the license? Not stated.
6. Is bin/console root-copy a supported long-term upgrade path, or a stopgap pending a proper vendor binary?
7. What is the maintenance commitment behind salaab — single maintainer or team?

Integration Approach

Stack fit. Treat this as a CLI toolkit for Sala-boilerplate projects, not as a Laravel dependency. It aligns with an existing Sala estate (where config/console.php, storage/psysh, and the stub layout are already the conventions) and with greenfield non-Laravel PHP services that want generators and a REPL. It does not fit a Laravel application that already uses Artisan, and it does not fit any environment pinned below PHP 8.4.

Migration path. There isn't one — this is v1.0.0, the initial release, and there is no prior assessment or prior version to migrate from. The realistic adoption path is greenfield: scaffold a Sala project and accept the console layer wholesale, or add sala/console to a non-Laravel service where Phinx would be the sole migration tool. For an existing Laravel codebase, the only defensible pattern is sidecar usage in a scratch or tooling context, never in the application's own runtime.

Compatibility. Pin sala/console:^1.0 exactly as documented and verify the resolved dependency tree before anything else — the illuminate/* range is wide enough that the same lockfile is unlikely to reproduce across PHP versions. Assume Laravel 10 + PHP 8.4 is an unsupported combination in practice. Budget for a compatibility spike: install into a throwaway Sala project on PHP 8.4, run list, then run one generator and one migration cycle end to end. That spike answers most of the open technical questions faster than maintainer correspondence will.

Sequencing.

1. Compatibility spike on PHP 8.4 in an isolated Sala project — confirm all 20 commands register and the binary auto-detects root correctly.
2. Decide the migration-ownership question explicitly and write it down; document that Phinx or Laravel's migrator is authoritative, never both, per environment.
3. If a Laravel pilot is still desired after (1) and (2), scope it to the REPL only (tinker), with storage/psysh excluded from version control and build artifacts, and with all generator/migration commands unused.
4. Only then consider the root-copied bin/console pattern, and document the upgrade procedure as a manual re-copy plus diff review.
5. Defer any decision on broad rollout until the PHP floor question is resolved.

Operational Impact

Maintenance. A v1.0.0 with no predecessor means the API contract is asserted, not proven — expect early point releases. Three independently-versioned ecosystem dependencies (Phinx, PsySH, Symfony Console) plus a wide illuminate/* range means upgrade timing is set by whichever moves first. The root-copied bin/console pattern adds a genuinely unbudgeted maintenance line: every package upgrade becomes a manual merge against each consumer project's copy. Ownership sits with salaab; the release notes read as a single-maintainer effort, and bus factor should be assessed before this becomes load-bearing for anything.

Support. No published license, no issue-triage or support commitment, and documentation currently lives in release notes rather than a README or docs site. Internal support burden will fall on whichever team adopts it. The config:publish/stub:publish commands helpfully expose the package's own conventions for local override, which lowers support cost somewhat — teams can patch behavior without forking.

Scaling. CLI tooling does not scale in the request-path sense; the scaling concerns are organizational. Two migration systems against a growing schema becomes an increasingly expensive problem to unwind the longer it persists. Parallel developer environments are a mild concern: per-project PsySH history and per-project .env loading are fine, but the auto-detection of project root in a monorepo or nested-checkout layout is a plausible source of confusing misbehavior at team scale. CI cost is negligible.

Failure modes. Ranked by likelihood, not severity:

• Split schema state from Phinx and Laravel migrations both running — the highest-cost failure, and silent until a rollback fails.
• Wrong .env loaded when root auto-detection resolves to a parent directory in a monorepo or nested checkout.
• Credential leakage via PsySH history in storage/psysh if that path is committed, synced, or included in a build artifact.
• Eloquent behavior drift between sala/console's manual bootstrap and Laravel's container-managed models — most likely to surface as missing model events or observers.
• Dependency resolution failure on illuminate ^10 + PHP 8.4 at install time; fails fast, but a blocked install on day one.
• Drift between root-copied bin/console instances across projects, producing environment-specific bugs that are hard to reproduce.

Ramp-up. Low for engineers already fluent in Artisan — the command surface is deliberately familiar, which is the package's clearest strength and its sharpest trap, since intuition transfers while semantics do not. The real ramp-up cost is conceptual, not mechanical: the team must internalize "this is not Artisan," and specifically that migrate here means Phinx. Budget a short internal write-up covering the migration-ownership decision, the storage exclusion for PsySH history, and the upgrade procedure for any root-copied binary. Two engineers, half a day each, is a reasonable estimate — assuming the compatibility spike has already run.