Garden Cli Laravel Package

Product Decisions This Supports

• Build vs. buy for internal CLI tooling: vanilla/garden-cli is a lightweight, Symfony Console-based command framework with configuration loading, a DI container, and module bootstrapping. It answers "do we hand-roll CLI scaffolding or adopt a small framework?" for standalone PHP tooling and Vanilla-adjacent products.
• Runtime baseline / platform roadmap: v4.0 is the PHP 8.1 compatibility release (PRs #43 and #45). The major version bump is the signal that PHP 8.1 is the new supported floor — this feeds directly into the "when do we raise the minimum PHP version across our services" decision.
• Ops surface consolidation: supports decisions about exposing maintenance workflows (batch jobs, migrations, seeding, forum/tenant maintenance) as first-class CLI commands rather than ad-hoc scripts.
• Dependency risk posture: single-vendor stewardship (Vanilla) with a small maintainer base. This informs whether to treat the package as a strategic dependency with a fork contingency, or as a disposable utility.
• Upgrade sequencing: v4.0 gives you a clean migration gate — either you are on PHP 8.1+ and can move to v4.0, or you stay on v3.1.2. Useful for cutting a coordinated upgrade train rather than per-repo drift.

When to Consider This Package

Adopt when:

• You maintain a Vanilla Forums-based product or a standalone PHP CLI application that wants a thin Symfony Console wrapper plus config/container bootstrapping, without pulling in a full framework.
• Your fleet is already on PHP 8.1+ — v4.0 is explicitly the 8.1-compat line; v3.1.2 remains the option for PHP 8.0 and below.
• You want a minimum-surface dependency you could realistically vendor or fork if upstream goes quiet.

Look elsewhere when:

• You are building a Laravel application. Artisan already provides console, container, and config integration; garden-cli duplicates that and adds a second bootstrapping model.
• You require an actively maintained dependency with a documented support matrix, security policy, or upgrade guides. v4.0 contains only two PHP 8.1 compatibility PRs, both from first-time contributors — thin release coverage and a low bus factor.
• You need new command-routing features, plugin ecosystems, or modern DX (prompts, output styling beyond Symfony's defaults).

How to Pitch It (Stakeholders)

For executives: v4.0 is a maintenance release, not a feature release. Its entire content is PHP 8.1 compatibility — one fix and one feature PR, both from first-time contributors. The major version number is the meaningful part: it marks PHP 8.1 as the supported runtime floor. There is no new capability, no deprecation, and no security content in this release.

For engineering: treat v4.0 as a platform-alignment upgrade, not a re-architecture. Gate the upgrade on your PHP 8.1 rollout being complete, then bump and smoke-test command registration, config resolution, and container bootstrapping — those are the surfaces the two compat PRs touch, and neither has broad test evidence behind it. If you are still on PHP 8.0 or earlier, stay pinned to v3.1.2; the v4.0 compare range confirms nothing was backported.

Recommendation: Adopt v4.0 where PHP 8.1+ is already the baseline. Do not schedule a migration effort for this release — fold it into the PHP baseline work you already owe. Avoid net-new products on this package outside the Vanilla ecosystem, and keep a fork path in reserve given the maintainer concentration.