- What is vest-kits/laravel used for?
- It is the official Laravel integration for the Vest kit, auto-discovering a service provider and facade so you get a fluent, framework-native API plus publishable configuration, Blade components, and Pest/PHPUnit assertions. In practice it also acts as a development-time quality layer, wiring Rector and PHPStan into the project, shipping opinionated GitHub Actions workflows, and integrating Laravel Boost. That places it in the build and CI path rather than in the request lifecycle.
- How do I install vest-kits/laravel with Composer?
- Run composer require vest-kits/laravel. The service provider and facade are auto-discovered, so you do not need to register anything manually in config/app.php. Publish the config file with php artisan vendor:publish and tune it per environment instead of editing files inside vendor.
- Which Laravel and PHP versions does vest-kits/laravel support?
- The package overview lists Laravel 10 and 11 on PHP 8.1 and above, but the v1.9.0 release tightens the requirement to Laravel ^13.33.0. Read the constraint in the composer.json of the exact version you plan to install rather than relying on the README, because a caret constraint on a new major acts as a hard install gate.
- Why does Composer fail to install v1.9.0 on a Laravel 12 application?
- Version 1.9.0 declares a caret constraint on Laravel ^13.33.0, which excludes Laravel 12 and every earlier major entirely, so Composer hard-fails instead of resolving. This is a breaking change shipped in a minor release, so treat it as a migration rather than a patch. Either upgrade the framework first or pin the package to an earlier release that still permits your Laravel version.
- Is vest-kits/laravel a runtime dependency in production?
- No. It sits entirely in the build and CI path, adding no middleware, migrations, or request lifecycle hooks, so it carries no runtime latency or availability surface. Rollback is effectively composer remove plus deleting the published config file. Note that Laravel Boost is declared at ^2.10.0, so it will be installed transitively whether or not you use it.
- How do I configure vest-kits/laravel for different environments?
- Publish the config file and adjust its values through environment variables rather than editing anything under vendor. Analysis levels, rule sets, and path scoping are settings you tune once and commit to the repository. Keep developer-specific overrides local so the shared configuration stays consistent across machines and pipelines.
- Do the generated CI workflows work on GitLab CI, Bitbucket Pipelines, or Jenkins?
- The PHP-side tooling works anywhere, but the shipped workflows target GitHub Actions, so teams on GitLab, Bitbucket, or Jenkins only get the Rector and PHPStan half of the value. Version 1.9.0 also bumps to checkout@v7, cache@v6, and upload-artifact@v7, which assume GitHub-hosted or recently updated GHES runners. If you run GitHub Enterprise Server, confirm the GHES version supports actions/cache@v6 before merging the generated workflow, since it tracks the newer cache service backend.
- How much effort does the PHPStan and Rector setup take on an existing codebase?
- On a brownfield project, expect the first PHPStan run to produce a large volume of findings that must be baselined or triaged individually. That triage, plus picking the analysis level, the Rector rule sets, and path scoping, is the dominant effort driver and is commonly underestimated. If you already maintain hand-rolled PHPStan, Rector, and CI configs, this package mainly replaces that bespoke maintenance with a maintained, versioned equivalent.
- Where are the Rector and PHPStan caches stored, and should I gitignore them?
- In v1.9.0 the caches move from the system /tmp directory to a project-relative tmp/ folder inside the repository. That is an improvement, giving per-project isolation, fewer cross-project collisions, and better behavior on ephemeral or containerized runners, but the directory must exist or be auto-created, must be added to .gitignore, and will accumulate over time. Watch for a committed tmp/ directory and for Docker build context bloat.
- Does vest-kits/laravel include testing helpers for Pest and PHPUnit?
- Yes. It ships ready-made Blade components and Pest/PHPUnit assertions so you can exercise the fluent API without writing custom scaffolding. Combined with the facade, that makes it straightforward to assert behavior in feature tests and in CI. Keep those assertions in your own test suite so they survive package upgrades.