Garden Cli Laravel Package

Technical Evaluation

What this is: vanilla/garden-cli is a standalone PHP CLI framework (command routing, argument/option parsing, interactive prompts, formatted output) maintained by Vanilla Forums. It is not a Laravel package — there is no service provider, facade, config publish, or Laravel-native integration surface. Any Laravel usage would be as a plain Composer dependency invoked from an artisan command or a standalone bin script.

Architecture fit: Low-to-moderate. Laravel already ships artisan (Symfony Console) as its CLI substrate. Adopting garden-cli means running a second CLI framework alongside Artisan, with duplicated dispatch, DI, and output-formatting concerns. The only defensible fit is a thin, self-contained tool (release/packaging script, data-migration utility, ops runner) that must work outside a bootstrapped Laravel app and where you don't want Symfony Console's verbosity. It is a poor fit for anything that needs Eloquent, the container, config, or queue access.

Integration feasibility: Mechanically trivial — one composer require, one entry script. Conceptually harder: Garden commands resolve their own dependencies, so bridging into Laravel's container is manual glue you own and maintain. No first-party Laravel documentation exists.

Technical risk (v4.0 specific):

• This is a major version bump whose changelog lists only PHP 8.1 compatibility work. Semantic-versioning convention implies a breaking change occurred, most plausibly a raised minimum PHP constraint and/or bumped transitive dependencies. The notes do not state this explicitly — treat the actual composer.json platform requirement and dependency diff as an unknown until verified.
• Release notes are effectively two PR titles from two first-time contributors. No upgrade guide, no deprecation list, no migration notes. That is a governance and change-transparency signal, not just a documentation nit.
• Maintenance concentration: a low-traffic, single-vendor-maintained framework. Bus-factor and long-term support are real concerns for anything load-bearing.
• Key questions to answer before adopting: (1) Exact PHP constraint delta between v3.1.2 and v4.0 — does it drop 7.x/8.0? (2) Full dependency diff, especially anything shared with Laravel (Symfony components, psr/*) that could conflict or force a lockfile bump. (3) Are there API/behavioral breaks in command definition or option parsing, or is the major bump platform-driven only? (4) Is there a v4.x maintenance commitment, or is this a one-off compatibility patch?

Integration Approach

Stack fit: Treat garden-cli as an isolated CLI utility layer, not an application framework. Recommended placement: a dedicated bin/ script with its own bootstrap, or a single Artisan command that shells out to a Garden-based binary. Do not try to make Garden the primary command bus for a Laravel app — you would be re-implementing Artisan for no gain.

Migration path (v3.x → v4.0):

1. Diff composer.json between tags v3.1.2 and v4.0 to confirm the platform requirement and dependency changes.
2. Run composer why-not vanilla/garden-cli 4.0 in the host project to surface conflicts before touching the lockfile.
3. Bump in a branch, run the full command suite (including interactive prompts — these are the most likely silent breakage point), and diff --help output for option-parsing drift.
4. Only then promote to the shared/base image.

Compatibility: Verify against the project's actual PHP matrix. If production runs PHP 8.0 or below, v4.0 is a hard blocker and v3.1.2 must be pinned. Also confirm that any Symfony Console / psr/log versions pulled in by Garden do not collide with Laravel's pinned versions — this is the most likely source of a painful transitive conflict.

Sequencing: (a) confirm platform requirement, (b) validate dependency graph in a scratch branch, (c) pin explicitly ("^4.0" only after validation; otherwise exact pin) and commit the lockfile, (d) run the command suite in CI, (e) schedule the PHP runtime upgrade if v4.0 is the forcing function.

Operational Impact

Maintenance: You own all integration glue. Upstream cadence appears low; releases arrive as compatibility patches when a PHP version lands. Budget for periodic forced upgrades driven by PHP EOL rather than by feature needs — v4.0 is precisely that pattern.

Support: No commercial support, no LTS branch, no security policy visible in the release notes. Internal escalation path is "read the source." For a CLI tool of this scope that is tolerable; for anything on a deployment path it should be documented as accepted risk.

Scaling: CLI-local, so runtime scaling is a non-issue. The scaling concern is organizational: every additional Garden-based tool multiplies the surface you must re-validate on each PHP upgrade, and the two-framework split (Artisan + Garden) raises onboarding cost for every engineer who touches the tooling.

Failure modes:

• Silent option-parsing behavior change after a major bump (interactive prompts and boolean flags are the usual casualties).
• Transitive dependency conflict with Laravel's Symfony pins, discovered late at lockfile resolution.
• PHP runtime upgraded in the app but Garden left pinned to v3.x — or the inverse — producing an environment-dependent failure that only reproduces in one image.
• Upstream stalls: no v4.x follow-up release, leaving the team carrying patches locally.

Ramp-up: Low for the concept (commands, options, prompts are familiar to anyone who has used Symfony Console), but there is no Laravel-oriented documentation, so expect engineers to read source and existing in-repo examples. Estimate a half-day for a competent PHP engineer to ship a first non-trivial command, plus ongoing cost from the two-CLI-framework mental model. Mitigate with a single documented reference command in-repo that new tools are expected to copy.

Recommendation: Adopt v4.0 only if a genuine need exists for a CLI outside the Laravel runtime. Pin explicitly, verify the platform requirement and dependency diff first, and keep the blast radius to one tool. If the goal is in-app tooling, stay on Artisan.