Package Command Laravel Package

Product Decisions This Supports

• Developer-environment provisioning (build vs. buy): This is the "buy" answer for distributing WP-CLI commands across a WordPress estate. It ships inside WP-CLI itself, so the decision is really "do we standardize on WP-CLI as our ops interface," not "do we add a dependency."
• Internal tooling distribution strategy: If we write custom WP-CLI commands for our WordPress platform, this package is the delivery mechanism (git URL, path, or zip installs; ^/~/@stable/dev-* constraints). Choosing it commits us to Composer as the packaging format for internal ops tooling.
• CI/CD and platform-standardization roadmap: --no-interaction, --format=json|csv|ids|yaml, and wp package is-installed (exit 0/1) make it scriptable. That supports gating pipelines on tool presence/version and generating machine-readable inventories of installed commands.
• Fleet maintenance and support retainers: list --fields=name,version,update,update_version and update give us a cheap drift/audit report across client sites — useful for SLA reporting and security-patch cadence on ops tooling.
• Feature scoping guardrail: The package index behind wp package browse is explicitly deprecated and frozen. Any roadmap item involving in-product package discovery ("browse and install community commands from a dashboard") has no supported data source — deprioritize or fund a replacement index separately.
• Security posture decisions: The existence of --insecure (disables TLS validation) and the GitHub-token-in-global-Composer-config workflow are policy questions, not code questions: we decide whether those flags are permitted in CI.
• Not a Laravel decision. Nothing here addresses Laravel application concerns (service providers, Eloquent, queue workers, HTTP tooling). If a stakeholder frames this as "a PHP package for our Laravel app," the correct PM response is to redirect: it is a WordPress-operations tool. It is only adjacent to Laravel work in that both use Composer, and even there the model differs — see below.

When to Consider This Package

Consider it when:

• We operate multiple WordPress installations and want a single, shell-scriptable interface for adding and updating operational commands (migrations, cache, search-index, backup wrappers).
• We are building internal WP-CLI commands and need a distribution channel that doesn't require hand-copying files onto servers.
• We want machine-readable environment inventory in CI (wp package list --format=json) or a pre-flight gate before running a pipeline step (wp package is-installed vendor/pkg).
• Our deployment target is a container image or golden VM where "install these packages at build time" is acceptable, and runtime mutation is not.
• We accept per-user, machine-global state (~/.wp-cli/packages/, overridable with WP_CLI_PACKAGES_DIR) as the operational model — e.g. an ops workstation or a build agent, not an application repo.

Look elsewhere — or deliberately constrain use — when:

• The project is Laravel or framework-only PHP. Use Composer directly; this package adds no value and introduces WordPress-shaped assumptions.
• We need per-project reproducible builds. The install target is a user's home directory, not the repo. There is no project-scoped lockfile to review in a pull request, so "what commands ran in prod last Tuesday" is not answerable from the codebase. For reproducibility, declare WP-CLI packages as project Composer dependencies and build them into the artifact.
• Anyone needs to discover packages. wp package browse reads a permanently frozen index. Build discovery elsewhere.
• The consumer is non-technical. This is a CLI for people comfortable with Composer, git URLs, and TLS errors.
• We need rich dependency governance (SBOM, vulnerability scanning per package, license auditing). Composer can do this; this wrapper's table output cannot, and it obscures which packages are transitive.
• Installing from a local directory is part of the plan: WP-CLI only stores a reference, so moving or deleting the directory silently breaks the install. Fine for active development, unacceptable for anything durable.
• Community traction matters to the decision. 18 stars and 0 dependents means we are not buying an ecosystem or a support community — we are using a small first-party utility. Judge it as such: low risk, low leverage.

How to Pitch It (Stakeholders)

To executives: This is not a new purchase or a new dependency — it is already bundled with WP-CLI, MIT-licensed, and maintained by the WP-CLI project. The cost of adoption is process discipline, not licensing or integration. Its value is narrow and real: it lets us install, pin, audit, and update the command-line tooling our WordPress operations depend on, in an automatable way. The risks are equally narrow: the package-discovery command depends on a deprecated index (so no roadmap bets there), and installs are per-user rather than per-project (so it must not become our reproducibility story). Recommendation: adopt as part of a WP-CLI standardization effort, provision at image build rather than at runtime, and pin versions.

To engineering: Treat this as a provisioning primitive, not a deployment tool. Use wp package install <name>:<constraint> at image-build time with --no-interaction; never rely on the home-directory install as the source of truth for what's running. Prefer declaring these packages in the project's composer.json where you need reviewable, lockfile-backed reproducibility, and use this command only where per-user tooling is genuinely the model. Use wp package is-installed as a pipeline gate and wp package list --format=json --skip-update-check for fast inventory (--skip-update-check also avoids GitHub/Composer auth flakiness in CI). Block --insecure in CI. Manage GitHub tokens via scoped secrets, not ad-hoc composer config -g on shared agents. Note also that any internal package we distribute must be a valid Composer package and pass Behat-based acceptance tests — that's real engineering overhead to budget for, not a free distribution channel.

To security and platform: Three items need explicit sign-off rather than default acceptance: the --insecure flag (TLS validation bypass, MITM exposure), the GitHub Personal Access Token being written to global Composer config on build agents, and the unpinned install path. All three are manageable with policy; none is a blocker.

Honest framing to avoid: Do not describe this as a Laravel or application-framework package. It is WordPress operations tooling. Any pitch that places it in a Laravel service's dependency graph will not survive technical review.