aaemnnosttv/wp-cli-valet-command
A WP-CLI extension for Laravel Valet that adds wp valet commands to create, manage, link, park, and destroy WordPress sites from the command line, streamlining local WordPress development with Valet-powered URLs and database setup.
aaemnnosttv/wp-cli-valet-command is a WP-CLI package that wraps Laravel Valet so WordPress sites can be created, registered, and torn down from the wp CLI instead of juggling raw valet commands plus manual database setup. It is the WordPress-side companion to your existing Valet workflow, not a Laravel package — you install it where WP-CLI lives, not via your app's composer.json.
Minimal setup:
# Prerequisites: Laravel Valet installed, WP-CLI installed
wp package install aaemnnosttv/wp-cli-valet-command
# Confirm the command registered
wp valet --help
Where to look first:
wp help valet and wp help valet <subcommand> — the authoritative list of subcommands and flags for your installed version.valet links — confirm what Valet currently knows about before debugging the package itself.First use case: scaffold a fresh local WordPress site through Valet in one flow, then use the same command family for existing checkouts:
wp valet new mysite # create + register a new local site
cd ~/Sites/existing-site
wp valet setup existing-site # register an already-present install
Scaffold-then-configure. Use wp valet new for the site skeleton, then chain standard WP-CLI commands to finish provisioning in a single script:
wp valet new mysite --locale=en_US
cd ~/Sites/mysite
wp core install --url=mysite.test --title="Mysite" \
--admin_user=admin [email protected] --skip-email
Register existing installs. For repos cloned into ~/Sites, run wp valet setup <name> from the project root so Valet links the directory and serves it at <name>.test. This is the everyday path for teams that keep WordPress in version control.
Teardown for repeatable local environments. Pair creation with wp valet destroy <name> in throwaway scripts so test fixtures don't accumulate stale links and databases in Valet.
Scripting around exit codes. Treat the package as a thin orchestration layer: check $? after each call rather than parsing human-readable output, and keep DB creation (wp db create) and config generation (wp config create) explicit so re-runs are idempotent.
Coexistence with Laravel sites. Valet serves PHP apps by directory convention; if a WordPress or legacy app doesn't live in a parked path, use Valet's own proxy commands rather than relying on this package — the package targets WordPress installs specifically.
Version pinning in team docs. Because the package installs into the global WP-CLI package directory (~/.wp-cli/packages), record the version in your onboarding docs and use wp package update deliberately rather than implicitly.
valet links and wp valet setup first.wp uses whatever PHP is on your PATH. A mismatch produces confusing WordPress errors or WP-CLI warnings. Check wp --info against valet use/valet status, and align them.wp package update; if warnings persist, they're likely from a different global WP-CLI package.composer.lock protecting you.sudo: neither Valet nor WP-CLI wants root; running either with elevated privileges creates permission problems in ~/.valet and ~/.wp-cli that are painful to unwind.--debug to any invocation, or export WP_CLI_DEBUG=1 for verbose output. Compare the package's output against the equivalent raw valet command to isolate whether the failure is in the wrapper or Valet itself.before_*/after_* hook system and WP_CLI::add_command are available if you need to wrap or augment behavior in your own mu-plugin-style CLI package.main.How can I help you explore Laravel packages today?