dxw / whippet

v2.10.1 2026-10-26 15:26 UTC

Requires

• php: ^8.3
• aura/autoload: ^2.0
• dxw/rubbishthorclone: ^1.0
• guzzlehttp/guzzle: ^7
• kevinlebrun/colors.php: ^1.0
• nikita2206/result: ^0.2.0

Requires (Dev)

• dxw/phar-install: ^1.1
• dxw/php-cs-fixer-config: ^2.0
• kahlan/kahlan: ^6.1
• mikey179/vfsstream: ^1.6
• mockery/mockery: ^1.1
• phpunit/phpunit: ^9.0
• vimeo/psalm: ^6

Unknown License

Published on Packagist.org on 2026-10-26 15:27 UTC

README

This project is a framework for building WordPress applications that eases deployment, plugin management and build steps. Whippet is part of dxw's work to build and host WordPress-based applications that conform more closely to 12-factor principles.

Whippet has a few basic goals:

1. Allowing proper build steps to take place, that automate build tasks both during development and deployment
2. Properly managing plugins and themes, allowing them to be version controlled and easily updated

Whippet can manage plugins and themes.

During development, whippet can be used in conjunction with wpc.

Whippet is under development and should be considered alpha software. If you use it, we'd love to know what you think.

Getting started

You will need:

• PHP
• Composer
• git

Install whippet

Via homebrew (recommended)

You can install Whippet via Homebrew by running:

brew install dxw/tap/whippet

From source

Whippet implements the scripts to rule them all pattern. To install Whippet from source, clone this repository:

$ git clone https://github.com/dxw/whippet.git

Then run the relevant script to setup your environment and install dependencies:

./script/setup

You might also want to symlink whippet to somewhere in your path:

sudo ln -s $PWD/bin/whippet /usr/local/bin/whippet

Using Whippet

The main things you can use Whippet to do are:

• Managing themes and plugins

Support

For dxw developers who will encounter Whippet in a support context.

See the Support doc.

Development and releases

When a new version is ready for release, open a PR updating the changelog accordingly.

Immediately after merging the release PR, you must:

1. Apply the version tag (format v1.2.3) to the latest commit on the main branch. You can either do this locally, then push the tag, or use GitHub's "Release" UI for this.

2. Apply the appropriate major version tag (format v1) to that same commit:

   git checkout main
   git pull && git fetch --tags -f
   ## Where v1.2.3 is the latest version you created in step 1, and `v1` is the respective major version
   git tag -f v1 v1.2.3
   git push origin v1 -f

3. Open a PR updating the dxw Homebrew tap to point to the latest release

Licence

MIT