- How do I install juststeveking/laravel-stubs in a Laravel app?
- Install it as a dev-only Composer dependency with composer require juststeveking/laravel-stubs --dev, then publish the stubs you want to override. Because it only shapes generated scaffolding, it does not need to be present in production. Check the README for the exact publish command and any provider registration.
- Which Laravel and PHP versions does laravel-stubs support?
- The stubs are written against a specific Laravel skeleton, and stub filenames change across framework majors, so confirm the supported Laravel and PHP versions in the repository before adopting. There is no guarantee of a tagged release per Laravel major unless the maintainer publishes one. Pin the package version and re-check stub names after every Laravel upgrade.
- How do I publish the stub files?
- Publishing copies the package's stub files into your application so Artisan's make:* commands render your versions instead of the framework defaults. The exact vendor:publish command and target paths are documented in the README. Commit the published stubs so the whole team generates consistent code.
- Does laravel-stubs only ship files or does it register a service provider?
- The decision to close before adopting is whether the package merely ships files or also registers a provider that overrides stub resolution. File-only means you can publish, vendor, and drop the dependency, while provider-based means an upgrade-time dependency you carry. Read the package's source directory and composer.json before choosing a path.
- Can I customize generated models, controllers, and form requests?
- Yes. The point of the package is to replace Laravel's default templates for models, controllers, migrations, jobs, events, policies, and form requests with an opinionated version that matches your conventions. You publish the stubs, edit them, and every subsequent make:* command uses your edited templates. Generated code then passes CI on the first run instead of needing manual cleanup.
- Do the stubs use declare(strict_types=1) and final classes by default?
- The package is described as opinionated, so expect defaults like strict types and possibly final classes, but read the shipped stub contents rather than assuming. Final classes and strict types can break mocking strategies and legacy untyped code paths, and those failures often surface weeks after adoption. Trial on one greenfield service with a one-commit rollback before rolling out broadly.
- What happens when Laravel changes stub filenames in a new major?
- Stub filenames track Laravel's skeleton and change across majors, and a stale or misnamed stub is not an error because the framework silently falls back to the default template. The failure mode is generated code quietly stopping to match your standard, which is a detection problem rather than a build failure. Add a CI check that compares generated output or stub filenames against the current framework skeleton.
- Will laravel-stubs conflict with another stub-publishing package?
- Yes, a second stub-publishing package in the same repository is the main collision risk, because resolution order and publish conflicts produce slow-to-diagnose incidents where a model generates from the wrong template. Keep exactly one source of truth for stubs per repository. If you already publish stubs another way, harvest the templates you want and drop the extra dependency rather than running both.
- Do generated files pass Pint, Larastan, and Rector without edits?
- Not guaranteed out of the box. Run the generated artifacts through your existing Pint, Larastan, and Rector configurations on a branch before adopting, because opinionated stubs and strict tooling rules can disagree. If generated code needs edits to pass, adjust the stubs rather than the tooling so the standard stays in one place.
- Is laravel-stubs maintained, and can I copy the stubs into my own repo?
- The repository shows a single maintainer, zero stars, and zero dependents, which is not evidence of poor code but does mean no one else is applying upgrade pressure. Plan for the maintainer to walk away and make sure nothing in your process depends on them. Confirm the license permits copying the stub files into your own repositories, since harvesting the stubs is a legitimate exit path.