Console Laravel Package

Product Decisions This Supports

Framing correction that drives every decision below: this is not a Laravel package in the conventional sense. It ships no service provider, no Artisan integration, and no config/app.php hooks. It is a standalone Symfony Console 7 toolkit that borrows Illuminate components (Eloquent, DB::) and swaps Laravel Migrations for Phinx. Treat it as the CLI layer of the Sala framework, not as an add-on to an existing Laravel app.

Build vs. buy

• Buying gets you ~20 commands on day one: serve, full Phinx migrate/rollback/status/breakpoint cycle, seeders, seven generators (controller, model, service, middleware, repository, view, migration), stub/config publishing, and a Tinker REPL. Realistically 2–4 engineer-weeks of scaffolding if built in-house, plus ongoing upkeep against Symfony Console 7 and Illuminate 12 churn.
• The bin/console universal entrypoint (standalone, copied to project root, or via vendor/bin/console) with auto root-detection, .env loading, config/*.php loading, and Eloquent bootstrap is the genuinely defensible piece. That bootstrap code is tedious, subtly bug-prone, and rarely written well the first time. It is the strongest argument for adoption.
• The generators are commodity. Price them near zero when evaluating; the bootstrap and the Phinx abstraction are what you are paying attention to.

Feature and roadmap decisions

• If your roadmap is "ship a new Sala-derived service every quarter," this package is a template-level dependency — it standardises project anatomy across services and pays back on every spin-up. Make it a required line in your boilerplate's composer.json rather than a per-project choice.
• If your roadmap is a single long-lived product with an established CLI, the marginal value is much lower. Cherry-pick the bin/console bootstrap pattern instead of adopting the whole dependency.
• The Tinker implementation is a real developer-experience lever: $app/$config preloaded, a db() helper bundling query builder plus DB::, Eloquent casters for Model and Collection, and per-project PsySH history in storage/psysh. Per-project history is a small detail with outsized effect on debugging velocity and onboarding. Worth calling out in your DX scorecard.

Adoption sequencing decisions this enables

• Safe to adopt early for generator and scaffolding use inside new Sala projects — low blast radius, easy to rip out.
• Defer on anything that writes to production data (db:drop, db:export, migrate, rollback) until you have validated Phinx parity against whatever your team knows from Laravel Migrations. This is the sharpest operational edge in the package.

Decisions this does not help with

• Nothing here informs your HTTP layer, queue, caching, auth, or observability choices. Keep this scoped as a tooling dependency in your architecture review, not a platform decision.

When to Consider This Package

Adopt when:

• You are on salaab/framework or a derivative. This is close to a no-brainer — it is the reference console for your own boilerplate.
• You are bootstrapping a greenfield PHP CLI-first or API-first service and want Phinx-based migrations rather than Laravel's. The migrate/rollback/status/breakpoint set is complete enough to run a real migration workflow.
• Your team already knows Laravel idioms and you want generator ergonomics in a non-Laravel or framework-light codebase.
• Your runtime is PHP 8.4+ and you control the host. See the constraint below.
• You want a REPL that actually knows your Eloquent models out of the box.

Look elsewhere when:

• You have an existing Laravel application. Use Artisan. This package gives you nothing Artisan doesn't, and introducing a second console binary with its own config loading and its own migration engine is a self-inflicted wound.
• PHP 8.4 is a blocker. The requirement is php ^8.4 — hard floor, no fallback. Shared hosting, older managed platforms, and conservative enterprise base images frequently lag. Confirm your deploy targets before this enters a composer.json.
• Phinx is a mismatch. If your team runs Laravel Migrations, Doctrine Migrations, or a platform-native tool, adopting Phinx for one package means two migration systems in one repo. That is a maintenance tax that outlives the convenience.
• You need vendor accountability. v1.0.0 is an initial release with no prior assessment and no adoption data. Maintainer concentration around a small boilerplate project is a genuine bus-factor and continuity risk. For a revenue-critical system, require a documented internal owner or a fork strategy before depending on it.
• You need version-range stability. illuminate/* ^10|^11|^12 is a wide, three-major window. Wide ranges are convenient now and a compatibility minefield later, since the package must satisfy three Laravel majors' worth of internal API drift. Expect lag on Illuminate 13.
• You want an LTS or support contract. None exists. Version 1.0.0 with a single commit reference is a starting line, not a guarantee.

Concrete gating criteria for a go decision: PHP 8.4 in production or staging today; no competing migration tool in the same repo; a named internal owner; and a two-sprint trial on a non-critical service that exercises migrate/rollback/breakpoint against a realistic schema before anything customer-facing.

One quality signal to weigh positively: Pest 3, Pint with the Laravel preset, and PHPStan level 5 are present from day one. That is above average discipline for an initial release and suggests the maintainer intends to keep it healthy. Level 5 is mid-tier, not strict — treat it as a good sign rather than a correctness guarantee.

How to Pitch It (Stakeholders)

To executives — one paragraph:

sala/console is a ready-made command-line toolkit for our Sala-based PHP services. It replaces roughly two to four engineer-weeks of scaffolding with a single Composer install, and it standardises how every new service is created, migrated, and seeded — which is where consistency across services actually comes from. The cost is one dependency line and a PHP 8.4 runtime requirement. The risk is maturity: this is a v1.0.0 from a small project, so we would adopt it behind a thin internal wrapper and validate the database commands on a non-critical service first.

To engineering — the honest brief:

• Symmetrical upside: you get a battle-tested-feeling bin/console bootstrap (root detection, .env, config loading, Eloquent wiring) that you would otherwise write by hand and get subtly wrong.
• Symmetrical downside: this is not Laravel. No Artisan, no service provider, no Laravel Migrations. It is Symfony Console 7 + Phinx + Illuminate 12 glued together. If you assume Artisan semantics — especially around migrations — you will be surprised in production.
• The Tinker build is the standout. Preloaded $app/$config, a db() helper spanning the query builder and DB::, Eloquent casters, and per-project history under storage/psysh. Debugging and onboarding both get faster.
• Hard floor is PHP 8.4. Verify CI and every deploy target before anyone types composer require.
• Guard the risky surface. Wrap db:drop, db:export, migrate, and rollback behind environment checks or a CI-only path. Never let db:drop be reachable from a laptop pointed at a shared environment.

To the architecture or platform review — the framing that gets it approved:

Treat this as a tooling dependency, not a framework commitment. It touches the CLI and nothing else — no HTTP kernel, no container, no runtime path in production request handling. Exit cost is low: the only genuinely non-portable piece is the bin/console bootstrap, and even that is ~a day to reimplement. Adopt with a wrapper, pin the version, and re-evaluate when Illuminate 13 lands or when adoption stalls.

The one-line version for a roadmap deck:

Standardises how our Sala services are scaffolded and migrated; buys back weeks per new service; costs us a PHP 8.4 floor and a small-vendor continuity risk we can contain with a wrapper and a pin.