Wp Cli Valet Command Laravel Package

Technical Evaluation

Scope note: despite the "Laravel/PHP package" framing, this is a WP-CLI package (aaemnnosttv/wp-cli-valet-command) that wraps the Laravel Valet CLI for WordPress workflows. It does not load inside a Laravel application, is not a Composer runtime dependency of any product, and is installed as a WP-CLI package (wp package install aaemnnosttv/wp-cli-valet-command). Treat it as developer-environment tooling, not application code.

Architecture fit: Sits in the local development layer only — provision/teardown of Valet sites for WordPress installs (wp valet new, valet park, isolate, which, destroy). It shells out to the valet binary rather than consuming a stable PHP API, so its correctness is bound to Valet's CLI surface and filesystem layout. Fits teams already standardized on Valet + WP-CLI; near-zero value otherwise.

Integration feasibility: Low effort. Single-package install, no app changes, no schema/config footprint. Constraints: macOS (or Valet Linux) hosts, WP-CLI present, valet on PATH for non-interactive shells. Reversible by wp package uninstall.

Technical risk: Moderate-to-low, and materially improved by v1.3.1:

• Patch release contains no breaking changes. Changes are a docs clarification (the requirement to register a site with Valet before commands succeed), an added GitHub Actions CI workflow, and fixes for PHP deprecation notices.
• The deprecation fixes are the substantive item: they indicate the package is being kept compatible with modern PHP (8.x) rather than bit-rotting. Prior to this, deprecation noise was a credible sign of staleness.
• The new CI workflow raises the quality signal from effectively "none" to "some automated validation" — but confirm whether it runs a test suite or only lint/install checks.
• Residual risks: single-maintainer project (bus factor), low commit cadence, no formal support or LTS, and tight coupling to Valet's CLI output/paths that a Valet major release could break.

Key questions:

1. Does the new GitHub Actions workflow execute tests against supported PHP/Valet versions, or is it lint/install only?
2. Which PHP and Valet major versions are validated (Valet 3.x vs 4.x)? Is there a stated support matrix?
3. Does it invoke valet as a subprocess (version-fragile) or use any stable API?
4. What is the expected behavior on Windows/WSL and in headless CI — hard failure or graceful degradation?
5. What is the maintenance contingency if the sole maintainer steps away? Is the codebase small enough to fork and patch internally?
6. Does the "register site with Valet" clarification map to a failure mode our engineers have actually hit (silent/no-op commands)?

Integration Approach

Stack fit: Adopt as optional developer convenience, not a mandated standard. Appropriate for teams on macOS + Valet + WP-CLI doing multi-site WordPress work; unnecessary for teams on Docker/Lando/DDEV/Trellis, where it adds a divergent local-environment path.

Migration path:

1. Baseline: engineers currently run valet link/valet park and valet isolate manually per project.
2. Pilot the package in one repo to replace those manual steps with scripted wp valet new / wp valet which invocations.
3. Codify as a pinned, reproducible install (Brewfile, devcontainer feature, or a make dev-setup target) rather than relying on ad-hoc global installs.
4. Deprecate the manual runbook once the scripted path is proven.

Compatibility: Pin the version explicitly (e.g. ^1.3.1). Because this is a global, per-machine tool, version drift is invisible and unsupported — record the expected version alongside the Valet and WP-CLI versions in onboarding docs. Do not add it to any application composer.json.

Sequencing:

• Week 1: validate ^1.3.1 against the team's actual PHP and Valet versions on one machine; confirm deprecation warnings are gone.
• Week 2: wire into the dev bootstrap script/Brewfile with the version pinned; add the Valet site-registration prerequisite to onboarding docs (the v1.3.1 clarification exists because people trip on this).
• Week 3: team rollout with a documented fallback to manual Valet commands.
• Ongoing: re-evaluate on any Valet major release or 6+ months without an upstream commit.

Operational Impact

Maintenance: Single maintainer, infrequent releases (v1.3.0 → v1.3.1). Acceptable for dev-only tooling with no production blast radius. The added CI is a positive maintenance signal; the absence of a support policy is not. Budget a light quarterly check: does it still install cleanly, and does it still work against the current Valet version?

Support: Community-only — GitHub issues, no SLA, no vendor. Internal ownership should sit with the platform/developer-experience function, with a named backup. Because the codebase is small, an internal fork is a realistic contingency and should be the documented fallback rather than a scramble.

Scaling: Zero runtime scaling concern — it never runs in production or CI for shipping artifacts. The scaling dimension that matters is team size: N engineers × M machines means configuration drift. Mitigate by pinning versions and driving installation through a shared bootstrap script, not per-engineer composer global require.

Failure modes to instrument and document:

• Valet CLI/path changes after a Valet major upgrade — commands fail or target wrong directories.
• PHP deprecation warnings resurfacing on newer PHP (the exact class of issue v1.3.1 addressed).
• valet not on PATH in non-interactive shells (CI, scripts, IDE tasks) — silent or confusing failure.
• Site not registered with Valet — command no-ops or errors; now documented, still worth a preflight check in the bootstrap script.
• Domain/TLD collisions and permission issues on the Valet config directory.
• macOS-centric assumptions breaking on Linux/WSL.

Ramp-up: Low — roughly an hour for an engineer already fluent in WP-CLI and Valet; the command surface is small and self-describing. The docs clarification in this release removes the most common first-run stumbling block. Non-Valet users should not be onboarded to this at all; for them the ramp-up cost is the cost of adopting Valet, not this package.

Recommendation: Approve as an optional, version-pinned developer convenience for Valet-based WordPress teams. v1.3.1 is a safe, non-breaking patch that improves the maintenance signal (CI added, PHP deprecations fixed) without changing the risk profile enough to justify broader standardization.