Cli Laravel Package

Technical Evaluation

Category correction is the first decision. statamic/cli is not a runtime Laravel package. It is a globally installed developer CLI that scaffolds a Statamic project (Statamic being a Laravel-based CMS), wires configuration, and exits. It belongs in the same intake lane as linters, formatters, and scaffolding tools — not the library lane. If it was scored against runtime-package signals, the 22.17 composite is a false negative and should not gate adoption.

• Zero dependents is structural, not a health signal. A CLI installed via composer global require or cpx never appears in an application's composer.json, so it cannot accrue dependents. The correct health proxy is first-party ownership: this is vendor-maintained tooling shipped by the same organisation that ships the CMS.
• 77 stars reflects audience size, not fitness. Statamic's installer audience is people who have already chosen Statamic. Low community gravity is expected for a narrow bootstrap tool and would only be alarming for a framework or integration library.

Architecture fit: high, strictly conditional. The tool occupies the developer-onboarding layer — it runs before a project exists and outside any request lifecycle we ship. It adds no runtime surface, no service registration, no config contract, and no security boundary to production. Fit is high if and only if we are standardising on Statamic. For plain Laravel or non-Statamic stacks it is inert. Where a mature internal scaffolding template already exists, adopting this as-is forks the golden path; the better architecture is to consume it as an inner layer beneath an organisation-specific wrapper.

Integration feasibility: high, gated on two items. Installation is a one-liner (cpx, which 3.7.0 explicitly recommends in #111), and there is no application-side wiring to design. Feasibility therefore reduces to environment floors and non-interactive behaviour.

Technical risk: low overall, concentrated.

• Minimum PHP and dependency bump (#115) is the only change with real breakage potential. It fails at composer install time during scaffolding, typically as an opaque dependency-resolution error that does not name the actual cause. Blast radius is small, but per-incident severity is high: because the CLI runs before the project exists, failure blocks onboarding outright with no fallback a new engineer can reason their way to.
• The license-key prompt (#117) is the second-order risk. In a non-TTY or scripted context an interactive prompt can hang rather than fail fast, converting a clean error into a CI timeout.
• Output changes (#110, #114, #118) are cosmetic for humans but invalidate log-scraping, snapshot assertions, and screenshot-based runbooks. Standing rule: never assert on human-readable CLI output.
• #119 ("remember stars") writes a local preference to developer machines and golden images — harmless, but state we should know exists before imaging at scale.
• Metadata anomaly: the listed last release is 2026-10-16. Verify tags against Packagist and the GitHub release feed before pinning; a future-dated release suggests a mirroring or registry inconsistency worth resolving at adoption time, not after.

Key questions to resolve before committing.

1. What are the concrete PHP and dependency floors in #115? This single fact decides whether the upgrade is a one-line pin bump or a coordinated environment programme across devcontainers, CI runners, and Docker base images.
2. Does the license prompt degrade gracefully in non-interactive shells, and is there a documented flag or environment variable to supply the key non-interactively? This gates all CI and scripted provisioning.
3. Is the CLI version coupled to the Statamic version it scaffolds, or can one CLI release produce a range of Statamic releases? This determines whether pinning the CLI also pins which Statamic versions we may adopt.
4. Where does the #119 preference persist, and can it be set centrally for imaged machines?
5. Is there a published support window or deprecation policy for older CLI majors?

Integration Approach

Stack fit. Laravel plus Statamic only. There is no partial-fit story: on plain Laravel the tool adds nothing, and on other CMS choices it is inapplicable. Within a Statamic standard, fit is across the board — greenfield evaluation, squad-level project creation, and CI-driven environment provisioning.

Integration pattern: wrapper, not fork. Adopt the vendor CLI as the inner layer and keep organisation-specific concerns (naming conventions, SSO bootstrap, cloud provisioning, secrets hydration) in a thin internal wrapper that calls it. This preserves vendor maintenance for the parts that churn fastest — license wiring, starter kits, setup hygiene — while keeping our golden path intact. If no wrapper exists and no backlog item does, adopt directly rather than build.

Migration path. This is additive and reversible: no production footprint, no data migration, uninstall is composer global remove. Where it displaces an internal scaffolder, run both in parallel for one sprint on the same project brief, diff the resulting repositories, then deprecate the loser. The decision that matters is not "how do we migrate" but "do we retire our generator" — and that should be answered by the parallel run, not by the release notes.

Compatibility gates, in order of blocking severity.

1. PHP and Composer floors (#115) on developer machines, devcontainers, CI runners, and Docker base images.
2. Interactive vs non-interactive behaviour of #117, including whether a key can be injected by flag or environment.
3. CLI-to-Statamic version coupling (question 3 above).
4. Availability of cpx and outbound network access to Packagist and the Statamic license service during provisioning.
5. Pin an exact version. Do not track latest — this is tooling with a fast-moving UX surface, and drift is invisible because nothing in composer.json records it.

Sequencing.

1. Environment audit: confirm PHP/Composer floors across images and runners.
2. Raise images and runners to the floor; do this before the CLI, never concurrently.
3. Pin the CLI version and bake it into the base dev image.
4. Validate non-interactive install in a throwaway CI job, with the license key supplied non-interactively.
5. Pilot with one squad; measure setup time against the 20–40 minutes of hand-assembly it replaces.
6. Document in onboarding, publish the internal wrapper, then declare default.

Operational Impact

Maintenance. The critical operational fact is invisibility: nothing in any application's composer.json records this dependency, so it will silently age. Assign a named owner and a re-audit cadence — quarterly, plus on any Statamic major — and subscribe to the GitHub release feed. Budget is near zero; the cost is attention, and attention is exactly what a dependency like this fails to attract.

Support. Expect onboarding ticket volume to fall, since setup variance is the usual source. But it introduces one new ticket class: "the CLI failed," which the reporter cannot debug because the failure happens before a project exists to inspect. Mitigate with a runbook covering the two known failure modes and a documented manual-scaffold fallback so a blocked engineer always has a next step.

Scaling. Per-developer cost is negligible; the scaling risk is drift, not load. Install at the image layer, not per-machine — that converts an unbounded fleet problem into a single build artefact. On CI, the multiplication is by job count: an interactive prompt that hangs instead of failing fast turns one bad job into a queue of them, which is why step 4 of the sequencing is non-negotiable before automation.

Failure modes, ranked.

• Dependency-resolution failure at scaffold time (#115): opaque error, blocks onboarding, pre-project so no fallback. Highest severity.
• Interactive prompt hang in non-TTY (#117): CI timeout instead of error; wastes runner minutes and confuses diagnosis.
• External dependency at provisioning time: both Packagist and the license service are on the critical path of project creation. Cache the CLI in images so Packagist is not required per-install.
• Output-format breakage (#110, #114, #118): only bites if we assert on human-readable output. Policy fix.
• Local state from #119: benign, but a hidden variable on imaged machines.

Ramp-up. Low and front-loaded. Roughly one to two hours of platform effort to pin, image, and document; effectively zero for developers once the base image carries it. The real ramp cost is organisational — getting images and runners to the PHP floor before the CLI lands, and socialising that the tool is the default. Do not sequence that backwards.

Recommendation. Adopt as developer tooling contingent on the environment audit and the non-interactive validation, with a named owner, a pinned version, and an image-layer install. No budget request; the decision this unlocks is whether the vendor CLI replaces or sits beneath the internal scaffolder.