Weave Code
Pest Plugin Init Laravel Package
pestphp/pest-plugin-init
A Pest plugin that adds an init command to quickly bootstrap Pest in an existing PHP or Laravel project, generating the baseline test configuration and scaffolding needed to start writing Pest tests.
The Pest Init plugin
Frequently asked questions about Pest Plugin Init
- How do I install pestphp/pest-plugin-init in a Laravel project?
- Install it as a dev dependency with composer require --dev pestphp/pest-plugin-init; Composer 2.2+ will also ask you to allow the plugin in config.allow-plugins. Once installed, the init command is exposed through the Pest CLI, so you can run it to generate phpunit.xml and the baseline tests scaffolding. Check compatibility first, because the published constraints target the Pest 1.x line and modern Pest 2.x or 3.x installs will likely fail to resolve.
- Do I still need pest-plugin-init with Pest 2 or Pest 3?
- No. The same scaffolding job, including phpunit.xml, tests/Pest.php, a base TestCase and the tests directory layout, was absorbed into Pest core and is now available through ./vendor/bin/pest --init. On Pest 2.x and 3.x the plugin's only extension point is redundant, so adding it brings a dependency with no functional gain.
- What files does the Pest init command generate?
- It scaffolds a phpunit.xml configuration, a tests/Pest.php file, the tests directory layout, a base TestCase, and the namespace and autoload conventions Pest expects. Because it rewrites files in place, commit a clean working tree first so the resulting diff stays readable in review.
- Is pestphp/pest-plugin-init compatible with PHP 8.3 and Laravel 11?
- The repository is archived, so there is no ongoing PHP 8.3 or 8.4 compatibility work and no security patching. Its composer.json most likely pins pestphp/pest to the 1.x line, which will conflict with a Laravel 11 stack running Pest 2.x or 3.x. Verify with composer why-not pestphp/pest before planning any Pest upgrade around it.
- Why does Composer block pest-plugin-init with an allow-plugins error?
- Composer 2.2 and later refuses to execute plugins unless they are explicitly listed under config.allow-plugins in composer.json. You can add the entry by hand or accept the interactive prompt during install. Note that the plugin also depends on Pest's plugin registration model via extra.pest.plugins and auto-discovery, which was reworked in Pest 2.x and 3.x.
- What is the difference between pest --init and the pest-plugin-init command?
- Functionally they do the same job: bootstrapping Pest into a new or existing PHP project. The plugin exposes an init command to the Pest CLI, while core Pest now ships the equivalent behaviour through ./vendor/bin/pest --init. For any current project the core command is the supported path, and the plugin should be treated as a legacy precedent rather than a component.
- How do I remove pestphp/pest-plugin-init from an existing Laravel project?
- Drop it from require-dev, delete any extra.pest.plugins entry and the matching config.allow-plugins line, then run the test suite to confirm phpunit.xml still resolves its bootstrap. If the scaffolding is still needed on a legacy 1.x tree, run the command once on a branch, inspect the diff, commit the generated files, and then remove the plugin instead of leaving it in the lockfile.
- Is pestphp/pest-plugin-init abandoned or still maintained?
- The repository is archived and has essentially no adoption, with 0 dependents and around 11 stars, so there is no downstream bug reporting or maintenance signal to read. Treat it as unmaintained dev tooling: no security patches, no PHP version work, and transitive drift whenever PHPUnit or Pest cuts a major release.
- Can a broken Pest plugin break my entire test suite?
- Yes, potentially. A plugin bootstrap failure can take down the whole suite rather than a single test, which is a high-noise failure for a low-value dev dependency. The blast radius is limited to developer laptops and CI, since this package has no production runtime footprint.
- What are the alternatives to pest-plugin-init for bootstrapping Pest?
- Use Pest core's built-in ./vendor/bin/pest --init, which generates the same baseline configuration and tests scaffolding. For legacy repositories where that behaviour genuinely matters, a short internal console command or a one-shot branch migration is cheaper and safer than forking the plugin or keeping archived code in your lockfile.
Weaver
How can I help you explore Laravel packages today?