Laravel Strict Stubs Laravel Package

Product Decisions This Supports

• Scaffolding conventions as a product-quality lever, not a product surface. The package ships strict replacements for Laravel's generator stubs so make:model, make:controller, and make:migration emit declare(strict_types=1), final classes, and explicit return types. Nothing here changes end-user behavior; it changes the first draft of every new file. Frame it as developer experience infrastructure and keep it off the customer-facing roadmap.
• Build vs. buy for code-generation templates. The real decision is whether the organization owns its skeletons in-repo (via php artisan stub:publish and committing the results) or consumes an external baseline. Given this package is archived, the honest answer for most teams is build: copy the ideas, publish your own stubs, and own them. Buying only makes sense if the upstream is actively maintained, and this one is not.
• Static-analysis and strict-typing adoption. If a roadmap initiative is "raise PHPStan/Psalm level" or "enforce strict types in new code," generated files are a recurring leak in that plan — every scaffolded class is an exception someone must remember to fix. Strict stubs close that leak at the source and make the CI gate honest from the first commit.
• Formatter-in-CI rollout. Generated code that fails php-cs-fixer/Pint on day one creates friction and noisy first commits. Stubs aligned to house style let a team enforce formatting with no carve-outs for app/ or database/.
• Onboarding and template hygiene. New hires judge a codebase by what the generator hands them. Strict, typed scaffolds shorten the path from make:migration to a reviewable PR and shift review attention from formatting to schema and domain design.
• Roadmap signal (negative). An archived, low-adoption repository is itself a data point: it tells you the Laravel ecosystem hasn't coalesced around one strict-stub baseline. That argues for treating this as an internal convention decision rather than a vendor selection.

When to Consider This Package

Consider adopting (or, more realistically, mining it for ideas) when:

• You want strict typing and final by default in newly generated files and have no house standard yet — read the stub files as a reference implementation, then publish your own.
• Your team already runs php-cs-fixer/Pint and static analysis in CI and is tired of hand-editing scaffolding output.
• You want a fast, concrete way to demonstrate the value of strict stubs to stakeholders before investing in a maintained in-house version.

Look elsewhere / do not adopt as a dependency when:

• The repository is archived. This is the dominant consideration. No Laravel-version support commitments, no response to upstream stub changes, no security or compatibility patches. Adopting an archived package as a production dependency is a standing liability, even for a dev-only tool.
• Adoption is effectively zero (single-digit stars). Low usage means you are the de facto maintainer if anything breaks, with no community to lean on.
• The value is copyable in an afternoon. These are static text files. php artisan stub:publish, a code review, and a commit get you the same outcome with no supply-chain surface and no dependency to track.
• Your conventions are already idiosyncratic. If you have customized stubs, you are maintaining a fork and the package's value is nominal.
• Last release was February 2023. Confirm compatibility with your current Laravel and PHP versions before assuming the stubs still match the generator expectations of recent Laravel majors — the stub set and generator behavior have moved since.

Net PM recommendation: treat this as research input, not a dependency. Vendor the ideas into your own published stubs.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a developer-tooling package that changes what php artisan make:* produces — strict types, final classes, explicit return types — so new code starts compliant with our quality gates instead of needing cleanup. It carries no runtime risk and no customer-facing impact. However, the project is archived, has negligible adoption, and has not been updated since early 2023, so I do not recommend taking it as a dependency. Instead I recommend a small, bounded internal task: publish our own strict stubs modeled on this package's approach. Cost is a day or two of engineering; the return is that every future scaffolded file arrives typed, formatted, and lint-clean, which compounds across the codebase and removes a recurring source of review friction. No resourcing beyond that, and no roadmap item.

For engineering (talking points): Don't add this to composer.json — it's archived and unmaintained. Do this instead: run php artisan stub:publish, then diff the published stubs against this repo's versions to borrow the declare(strict_types=1), final, and explicit-return-type conventions. Adapt to our Pint/php-cs-fixer config and commit. Watch for three things: (1) Laravel has changed stub contents across majors, so start from our Laravel version's stubs rather than copying wholesale; (2) final by default breaks mocking and extension in tests — decide deliberately whether models, controllers, and migrations all get it, and document the exception path; (3) declare(strict_types=1) in generated files can surface latent type-coercion bugs elsewhere in the call path, so land it early in a release cycle with a green CI run rather than mid-freeze. Add a short note to the contributing guide so new scaffolds don't get hand-edited back to the old style.