Cli Laravel Package

Product Decisions This Supports

• Trial-to-adoption conversion: statamic/cli is the first-run experience for a Statamic project. The 3.7.0 polish—collapsed install output (#110), tidied step output (#118), success messaging in a callout (#114), and fixing the stale-version warning on local checkouts (#113)—directly reduces perceived setup complexity. For a PM, this is a lever on how quickly evaluators get from “fresh install” to “I have a working CMS,” which matters when comparing Statamic against WordPress, Craft, or headless alternatives.
• Licensing funnel design: Prompting for a Statamic license key during install (#117) moves a post-install documentation step into the flow. This shortens the path from evaluation to licensed production use, but adds friction for exploratory users and automated environments. Treat it as a deliberate funnel decision: validate whether the prompt can be skipped or supplied non-interactively before making it a universal default.
• Build vs buy for project scaffolding: If your platform team has a backlog item for “create a new Statamic project,” this package is the vendor-maintained alternative. The 3.7.0 release reinforces that the official CLI is the maintained path for scaffolding, license wiring, and setup hygiene. Default to adopt/buy unless you already have a mature golden-path generator that covers Statamic cleanly.
• Developer experience roadmap input: “Recommend cpx for installing the CLI” (#111) and “remember stars” (#119) are first-run polish and community-affinity features, not platform capabilities. They signal that upstream investment is going into onboarding consistency and developer habits. That is useful when deciding whether to defer internal tooling work in favor of upstream.
• Environment standardization: The minimum PHP and dependency bump (#115) is a portfolio-level governance item. It sets the floor for new projects, developer images, CI runners, and Docker base images. A PM should treat this as an environment decision, not just a CLI upgrade.
• Interpreting low community signals: Zero dependents is expected because a globally installed CLI never appears in an application’s composer.json. A low star count reflects a narrow Statamic audience, not poor fitness. The health proxy is first-party vendor ownership—this is official Statamic tooling maintained alongside the CMS.
• Supported use cases: Greenfield Statamic evaluation, standardized project creation across squads, CI-driven environment provisioning with reproducible installs, and reducing onboarding support tickets for new hires.

When to Consider This Package

Adopt when:

• You are standardizing on Statamic and want a vendor-maintained, low-effort path to scaffold new projects.
• Multiple developers or squads repeatedly create Statamic environments, and inconsistent setup is creating support load.
• You want install-time configuration prompts, such as license key entry, to enforce hygiene at project creation rather than through documentation.
• Your CI/CD or local provisioning can consume a scriptable installer. The output cleanup in #110, #114, and #118 makes logs easier to read, but do not build strict assertions against human-readable output.
• You can standardize the PHP and dependency floor required by 3.7.0 across developer machines and CI images.

Look elsewhere or defer when:

• You are not on Statamic. This is vendor-specific tooling and provides little value for plain Laravel or other CMS choices.
• You already have mature internal scaffolding. If your golden-path repo or generator already handles Statamic setup, adopting this may fork your developer workflow rather than simplify it. Consider using it as an inner layer only if it composes cleanly.
• Your fleet is pinned to older PHP versions. The dependency and PHP minimum bump (#115) is the main compatibility gate. Confirm the exact floor before recommending this version as default. Shared hosting, legacy monoliths, and unmaintained Docker images may require an unrelated upgrade project.
• You need fully unattended installs. The new license-key prompt is useful for correctness but risky in non-TTY or automated contexts. Validate that it fails cleanly or can be supplied non-interactively before putting it into CI.
• You need vendor-neutral, long-term-stable interfaces. A CLI installer is convenience tooling with a fast-moving UX surface, not an API contract. Avoid depending on exact output text, screenshots, or log formats in automation.
• You need a published support window or deprecation policy. If “track latest” is the implicit contract, set a re-audit cadence and name an internal owner—this dependency will otherwise drift because it is invisible in composer.json.

Before committing, resolve: the concrete PHP and dependency floors introduced by #115; whether the license-key prompt (#117) degrades gracefully in non-interactive shells and whether a flag or environment variable exists; whether the CLI version is coupled to the Statamic version it scaffolds; where the “remember stars” preference (#119) persists and whether it can be set centrally for imaged machines; and the support/deprecation policy for older CLI majors.

How to Pitch It (Stakeholders)

To executives: This is the official command-line installer for Statamic, our Laravel-based CMS option. It is a developer-experience tool, not a runtime dependency, and carries no production footprint. The 3.7.0 release improves first-run experience: cleaner install output, better success messaging, and a license-key prompt that shortens the path from evaluation to paid production deployment. The only governance item is a minimum PHP and dependency bump, so we should confirm our supported runtime floor before making it the default. Recommendation: adopt after a short environment audit; no budget request.

To engineering: Treat this as a developer-tooling dependency, similar to a linter or formatter, not as a Composer library in application code. Pin a version, document it in onboarding, and include it in the base dev image. The PHP/dependency minimum bump (#115) is the main compatibility gate: raise developer machines, devcontainers, and CI images first, then bump the CLI. The license-key prompt (#117) improves correctness but may hang scripted installs; validate non-interactive behavior before wiring it into automation. Output formatting changes (#110, #114, #118) improve readability but should not be treated as a stable interface. Fix #113 is a quality-of-life improvement for local checkouts. Assign a named owner because this tool will not appear in composer.json.

To product/design: This release is a useful first-run experience case study: collapse verbose output, move success messaging into a callout, and ask for the license key at the moment it matters. The pattern is worth borrowing for our own onboarding flows, especially where setup complexity affects trial conversion.