Pest Plugin Init Laravel Package

Product Decisions This Supports

• Build vs. buy vs. adopt — resolved toward "build in core." The package exists, has effectively zero adoption (11 stars, 0 dependents), and is archived precisely because its one capability was absorbed into Pest core (./vendor/bin/pest --init). That is a clean, low-cost precedent for a decision we will face on our own CLI/SDK roadmaps: scaffolding and first-run setup belong inside the core product surface, not behind a plugin boundary.
• Developer onboarding as a roadmap line item. The package sits at the "first five minutes" of the developer experience — bootstrapping a test runner, generating phpunit.xml and tests/Pest.php, laying out the test directory. Use it as a scoping artifact for what an init flow must touch: existing-config detection, namespace and test-path conventions, idempotent re-runs, partial-failure recovery.
• Legacy migration strategy. It informs the PHPUnit → Pest conversion question: should "one-command migration" be a product feature we own, and should it be incremental (keep *Test.php classes running as-is, convert file-by-file) rather than a big-bang rewrite?
• Dependency governance policy. A textbook entry for an approved-dependency policy: archived, unmaintained, no community validation, no security response path. Reference implementations get read, not required.
• Guardrail against a false demand signal. The opportunity: 21.53 score is an artifact of zero adoption on an archived repo, not evidence of an underserved niche. Write it down so a future evaluator doesn't burn a spike rediscovering it.
• Where it is genuinely relevant: greenfield test-harness bootstrapping, legacy suite modernization programs, DevEx/developer-enablement initiatives, and as a worked example for engineers writing their own Composer-installed console command.

When to Consider This Package

Consider it — as reference material, not a dependency — when:

• You are scoping an init/scaffold/codemod command and want a small, real example of the edge cases: partially-initialized projects, non-standard test paths, custom namespaces, re-running after a partial failure.
• You are maintaining a legacy Pest 1.x codebase where init behavior lived outside core.
• An engineer needs a minimal example of plugin structure (service provider, command registration, config publishing) for a different plugin entirely.
• You want a documented precedent for the "feature graduated from plugin to core" pattern in an architecture or roadmap discussion.

Look elsewhere when:

• You are on Pest 2.x or 3.x — the flow is built in (./vendor/bin/pest --init); adding this risks conflicting behavior for no gain.
• You need maintenance guarantees: security patches, PHP 8.3/8.4 or current Laravel support, or any compatibility commitment. There will be none.
• You need a general-purpose migration engine (Rector, Laravel Shift, a custom Composer plugin). This is narrow, single-purpose scaffolding.
• Any production or CI-critical dependency requirement exists. Zero dependents means zero downstream bug reports to learn from and no knowledge base when something breaks.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a small, archived plugin that bootstraps Pest inside a PHP project. It has essentially no adoption and has been superseded — the capability now ships inside Pest itself. Recommendation: do not adopt it. Invest one engineer-hour reading it as a design reference, extract the UX checklist for our own onboarding flow, and move on. Cost: negligible. Risk: zero, because nothing ships with it.

For engineering (the actual ask): Don't add this to composer.json — it's archived, unmaintained, and duplicated by current Pest core. Treat it as documentation instead: read the command class for how it handles existing phpunit.xml files, test-directory and namespace detection, and idempotency on partially-initialized projects, then point anyone who needs the behavior at the built-in pest --init. If it appears in a lockfile anywhere, that is a removal task, not an upgrade task — drop it from require-dev, run core --init, clear any extra.pest.plugins and allow-plugins entries, and run the suite; roughly 30–60 minutes per repo. If we build our own scaffolding command, this is a 20-minute source of edge cases.

Strategic takeaway to carry forward: the plugin-to-core graduation pattern is a useful lens. Capabilities at the very first touchpoint of the developer experience — install, init, upgrade — tend to migrate into the core product, because the plugin boundary adds friction exactly where friction is most expensive. Plan accordingly: design our scaffolding as a core command with a stable interface from day one, rather than as an ecosystem extension we will later have to absorb or abandon.