# wordpress-package-cli

CLI wrapper for the Probots WordPress Docker and workspace workflow.

## What it provides

- Docker lifecycle commands such as `up`, `down`, `dev`, `logs`, and `shell`
- container passthrough commands such as `cli`, `composer`, and `yarn`
- `package` command bridging for package CLIs like `blocks-cli` and `base-cli`
- project setup helpers with `create`, `doctor`, `export`, and `release`

## Common commands

```bash
wp up
wp doctor
wp dev
wp logs
wp shell
wp cli plugin list
wp composer install
wp yarn build
wp package theme.generate
wp package wp:block:create
wp create my-project
wp export
```

## Project Bootstrap

Use `wp create` as the supported starter bootstrap path. It clones the starter, initializes git, runs `git flow init`, writes `.env`, runs `wp doctor`, starts Docker, installs dependencies, and runs the WordPress install script.

```bash
mkdir my-project && cd my-project
wp create --repository=git@github.com:your-org/your-project.git
```

Use `wp doctor` anytime to verify local prerequisites and the current starter checkout:

```bash
wp doctor
```

## Workspace Compose Overrides

When working from the internal multi-repo workspace, `./sandbox.sh` copies this into `__sandbox__/.env`:

```bash
CLI_COMPOSE_FILES=docker-compose.yml,../workspace/docker-compose.workspace.yml
```

That lets normal commands like `wp up`, `wp dev`, `wp yarn`, and `wp composer` run against both the sandbox compose file and the workspace override.

## Local Package Development

For theme Composer commands, use `--workspace` to temporarily prepend a local Composer `path` repository for `../../package-*`:

```bash
wp composer install --workspace
wp composer update probots/wordpress-package-blocks --workspace
```

This keeps the checked-in theme `composer.json` clean while letting local package checkouts win over the remote package registry during development.

Typical workspace flow:

```bash
./sandbox.sh

cd __sandbox__
wp up
wp composer install --workspace
```

## Release

```bash
wp release
```

`release` expects a clean git worktree, calculates the next semantic version from tags, creates a release branch, merges to `master` and `develop`, tags the release, and pushes the result.
