Laravel Blueprint Pestphp Addon Laravel Package

Product Decisions This Supports

• Scaffolding velocity for new Laravel services: Blueprint turns YAML "draft" files into models, migrations, controllers, factories, and tests. This addon swaps the generated PHPUnit tests for Pest equivalents, so teams standardizing on Pest can keep using draft-file-driven generation instead of hand-writing test scaffolding. Directly supports "time-to-first-endpoint" and "time-to-first-green-test" metrics for greenfield work.
• Test-framework standardization: Choosing Pest is a team-wide convention decision. This package makes that convention viable inside a Blueprint workflow, which is a factor in the build-vs-buy (write our own Blueprint addon vs. adopt this) calculus. Adopting it is cheap; writing and maintaining a private addon is not.
• Roadmap coupling to Laravel majors: v2.3.0 adds Laravel 10 and drops Laravel 9, mirroring Blueprint's own support policy of generating code for the latest conventions. This is a planning input: staying on this package means staying roughly current on Laravel majors, and upgrade windows must be scheduled alongside framework upgrades.
• Use cases it unlocks: rapid prototyping of CRUD domains, internal admin tools, demo/PoC environments, and training scaffolds where generated code and generated Pest tests give reviewers something runnable quickly. Less relevant for mature codebases where scaffolding is rare and hand-written tests dominate.
• Not a runtime dependency: this is a dev-only generator addon. It carries no production risk surface, which keeps the cost of adoption and reversal low — a useful property when arguing for a trial.

When to Consider This Package

Consider adoption when all of the following hold:

• Your team uses laravel-shift/blueprint for code generation from draft YAML files.
• Your team has standardized on Pest as the test framework; generated PHPUnit tests would be immediately rewritten or discarded.
• You are on Laravel 10 (or later, as support is added). As of 2.3.0, Laravel 9 is no longer supported — teams mid-upgrade should pin to 2.2.x until their framework upgrade lands.
• You want generated test scaffolding that matches house style closely enough that reviewers do not rewrite it.

Look elsewhere or skip when:

• You do not use Blueprint at all — the addon has no purpose without it.
• You are staying on Laravel 9 or older for a defined period; you need the 2.2.x line and should track it deliberately rather than float the constraint.
• You use PHPUnit, or you have an internal test-generation convention already wired into your Blueprint fork.
• Generated tests are not actually used in your workflow — many teams scaffold models and controllers but write tests by hand. Verify this before adding a dependency.
• You need a stable, broadly-maintained tool with a large contributor base; this is a small, single-maintainer addon whose release cadence tracks Laravel majors rather than a fixed roadmap.

How to Pitch It (Stakeholders)

For executives: This is a small, free, dev-only addon that plugs into our existing Blueprint code-generation workflow so the tests it generates come out in Pest, the framework our engineers already use. It does not ship to production, adds no runtime risk, and removes a manual rewrite step every time we scaffold a new feature. The cost is a package in our dev dependencies and one upgrade to track per Laravel major.

For engineering: Adopt on Laravel 10 projects that use Blueprint plus Pest. It eliminates the "generate tests, then convert them" tax and keeps generated tests idiomatic, which makes them more likely to survive review instead of being deleted. Be explicit that 2.3.0 is a breaking change for anyone on Laravel 9 — pin ^2.2 on those projects and plan the bump with the framework upgrade. Because the addon follows Blueprint's "latest conventions" support policy, expect a similar break at each Laravel major; budget it as a recurring, low-effort upgrade line item rather than a one-off. Given the low blast radius (dev-only, easily reverted), the sensible path is a trial on one new service, measuring how much generated test code is kept versus rewritten, before making it a default in our scaffolding template.