WP Playground Project Blueprints
TYPESCRIPT · PLAYGROUND CLI
Hand-written Playground blueprints break silently at runtime — a mistyped step or wrong resource shape fails in the browser with no useful message. This validates every blueprint in CI before anyone clicks the link.
- Maintainer
- Pixy Puala
- Vertical
- Developer experience · Playground
- Year
- 2026
- Role
- Open source
- Stack
- TypeScript
- Status
- ● Public repo
- Verified
- Source on GitHub
Problem
Getting a reviewer, a contributor or a support engineer into a reproducible WordPress environment is the slowest part of every bug report. Playground solves it, but only if the blueprint is correct — and nothing checks that until it fails in front of the person you were trying to help.
Constraints
Decisions
Validate every shipped blueprint in CI
The suite tests the validator and each blueprint on Node 20 and 22, so a broken demo link cannot reach main.
Model the step enumeration precisely
login, installPlugin, runPHP, runSql, importWxr, wp-cli and the rest are modelled with precise error paths — a vague "invalid blueprint" message would leave the author no better off.
Stop at the descriptor boundary
The zip step builds the resource descriptor; fetching zip bytes over the network belongs to a runner and is out of scope by design.
Build
Stack
- ▸ TypeScript · Node 20+ · pnpm
- ▸ CLI (dist/cli.js) · blueprint JSON validation
- ▸ Hand-modelled BlueprintV1 schema · step enumeration
- ▸ Vitest
- ▸ CI on Node 20 and 22
Tooling
- ✓ kept pnpm · Vitest · GitHub Actions
Results · Measured
Every blueprint shipped in the repository is validated by the suite, so the collection cannot drift away from the schema it advertises.
Tradeoffs
Building or fetching zip bytes over the network is deferred to a runner outside this repository. The validator models the descriptor, which is where blueprint authors actually make mistakes.