- What is aaemnnosttv/wp-cli-valet-command?
- It is a WP-CLI package that adds wp valet subcommands wrapping the Laravel Valet CLI, so you can create, manage, link, park, isolate, and destroy local WordPress sites from the terminal. It is developer-environment tooling for your machine, not application code, and it does not load inside a Laravel application. Its value is highest for teams already standardized on macOS, Valet, and WP-CLI.
- How do I install aaemnnosttv/wp-cli-valet-command?
- You need WP-CLI installed and Laravel Valet set up with the valet binary available on your PATH. Then install it globally as a WP-CLI package with wp package install aaemnnosttv/wp-cli-valet-command and start scaffolding sites with wp valet new. Do not add it to any project composer.json, since it is a per-machine tool rather than an application dependency.
- Can I require this package in my Laravel app with Composer?
- No. Even though it is distributed through Composer, it is a WP-CLI package that only loads inside WP-CLI, not a Laravel application. Adding it to your app's require block provides no runtime benefit and creates confusion about where it belongs. Install it globally on developer machines instead.
- Which Laravel Valet and PHP versions does it support?
- The package shells out to the valet binary rather than consuming a stable PHP API, so its compatibility follows Valet's CLI surface and filesystem layout rather than a documented support matrix. Version 1.3.1 fixed PHP deprecation notices, signalling ongoing PHP 8.x compatibility, and added a GitHub Actions CI workflow. Because no formal Valet 3.x versus 4.x matrix is published, validate against your own versions and pin the package explicitly, for example ^1.3.1.
- Why do my wp valet commands appear to do nothing?
- Version 1.3.1 clarified in the docs that a site must be registered with Valet before the commands succeed, which is a common cause of silent or no-op behavior. Also confirm that valet is on PATH for non-interactive shells, since scripts and bootstrap targets often run with a different environment than your interactive terminal. Finally, verify the WP-CLI package is actually installed and on the version you expect.
- What commands does wp valet provide?
- It adds subcommands such as wp valet new to spin up a fully functional WordPress install, along with park, link, isolate, which, and destroy for managing existing sites. These mostly wrap the equivalent Valet operations so you can stay in one CLI workflow. Because they delegate to the valet binary, their behavior tracks whatever Valet version you have installed.
- Does it work on Linux, Windows, WSL, or in headless CI?
- It is designed around macOS Laravel Valet, with Valet Linux as a possible host, and it requires both the valet binary on PATH and WP-CLI present. On Windows, WSL, and headless CI environments, expect hard failures because Valet and its filesystem assumptions are not available. Treat it as a local developer convenience and do not build CI pipelines that depend on it.
- What are the alternatives to this package?
- You can keep running valet link, valet park, and valet isolate manually per project, which is what this package scripts for you. Alternatively, use container-based environments such as DDEV, Lando, Trellis, or Docker, which avoid depending on Valet entirely. If your team already standardizes on macOS plus Valet, this package removes manual steps; on Docker-based stacks it adds a divergent local environment path.
- Is aaemnnosttv/wp-cli-valet-command still maintained?
- It is a single-maintainer project with low commit cadence and no LTS or formal support commitment, so bus factor is a real consideration. Version 1.3.1 is a positive signal: it added GitHub Actions CI, a docs clarification about registering sites with Valet, and fixes for PHP deprecation notices. Confirm whether that workflow runs a full test suite or only lint and install checks, and keep in mind the codebase is small enough to fork and patch internally if needed.
- How should a team standardize, pin, or remove this tool?
- Pin the version explicitly, for example ^1.3.1, in a Brewfile, devcontainer feature, or make dev-setup target instead of relying on ad-hoc global installs, and record the expected version alongside Valet and WP-CLI in onboarding docs. Pilot it in one repository before deprecating your manual valet runbook. To roll back, run wp package uninstall aaemnnosttv/wp-cli-valet-command, which leaves no application schema or config footprint.