Wp Cli Stubs Laravel Package

Product Decisions This Supports

• Static-analysis coverage as a quality gate. This package lets PHPStan/Psalm resolve WP_CLI:: static calls, WP_CLI\Utils\* helpers, and WP-CLI command classes without loading WP-CLI at analysis time. That directly supports the decision "do we raise our PHPStan level and enforce it in CI for our WP-CLI surface?" — the answer becomes yes far more cheaply than writing or hand-maintaining declarations.
• Build vs. buy for internal tooling. The alternative is generating and curating your own stubs from the installed WP-CLI version (php-stubs/generator) or running analysis against the full wp-cli/wp-cli-bundle in vendor/. This package is the "buy" (adopt) option: a tiny, MIT-licensed, declaration-only dev dependency that removes an internal maintenance task from the roadmap.
• Scoping the developer-experience roadmap. Whether to invest in IDE autocompletion and inline type hints for teams writing custom WP-CLI commands (migrations, data backfills, ops runbooks). Adoption here is a low-cost enabler for those internal tooling bets.
• Risk decisions on runtime vs. dev dependencies. Because it ships only declarations and belongs in require-dev, it can be evaluated as a pure DX/CI decision with no production runtime, attack-surface, or autoload-footprint impact — decoupled from release risk.
• Use cases it unlocks: custom WP-CLI command packages inside plugins/themes, agency scaffolds that standardize on WP-CLI for deploys and data operations, and any repo where WP-CLI is used but not vendored (common in Bedrock-/Composer-managed WordPress installs).

When to Consider This Package

Adopt when:

• You maintain custom WP-CLI commands (WP_CLI::add_command, WP_CLI::success/error/log, WP_CLI\Utils\get_flag_value, WP_CLI::confirm, etc.) and want them type-checked.
• You already run PHPStan or Psalm in CI (or plan to) and need WP-CLI symbols resolved without scanning a large vendor tree.
• WP-CLI is not a Composer dependency of the project (typical for plugins/themes), so analysis can't otherwise see its API.
• You want IDE autocompletion and signature help for WP_CLI::* with near-zero setup.
• You pair it with php-stubs/wordpress-stubs and pin stub versions in lockstep with the WP-CLI version your CI runners use.

Look elsewhere or de-scope when:

• You write no WP-CLI code — the value is exactly zero; don't add noise to composer.json.
• You need WordPress core, plugin, or third-party API stubs — those are sibling packages; this one is WP-CLI only.
• You rely on WP-CLI internals or version-specific behavior not covered by the stub release — verify coverage first; a mismatched stub version silently weakens analysis or produces false positives.
• You require vendor-backed support or a large maintenance signal. With ~30 stars and 0 dependents, this is a single-maintainer, niche artifact: bus-factor and lag-behind-WP-CLI-release risk are real. Mitigate by pinning an exact version and keeping php-stubs/generator as a documented fallback.
• You're on an old PHP toolchain — confirm the stub release targets your PHP/PHPStan versions and your WP-CLI major version.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a free, MIT-licensed, development-only package that adds type information for WP-CLI — the command-line tool our teams use for deploys, migrations, and data operations. Adding it means our static-analysis and CI checks can actually validate that code, catching bugs before they reach production. Cost: one line in composer.json, no runtime dependency, no production risk. The tradeoff is maintenance concentration in a small open-source project, which we contain by pinning a version and keeping an internal fallback to generate stubs ourselves — roughly an hour of work if the project stalls.

For engineering: Add php-stubs/wp-cli-stubs to require-dev and register its path in phpstan.neon/Psalm config. It supplies declaration-only stubs for WP_CLI and the WP_CLI\Utils helpers, so PHPStan can resolve static calls without booting WP-CLI or scanning wp-cli/wp-cli-bundle in vendor/ — faster analysis, fewer ignoredErrors entries, and real signatures in the IDE. Pair it with php-stubs/wordpress-stubs, pin both versions in composer.lock, and align the stub version with the WP-CLI version on our runners. Known caveat: the project is small (~30 stars, no dependents), so treat the stub version as a tracked dependency and document the php-stubs/generator fallback. Success metric: PHPStan level increases on WP-CLI-touching packages with no growth in baseline suppressions.