Laravel Stubs Laravel Package

Product Decisions This Supports

• Scaffolding conventions as product infrastructure. Decides whether php artisan make:* output (models, controllers, form requests, policies, jobs, events, migrations, tests) lands in the repo already matching team standards — declare(strict_types=1), final classes, typed properties, promoted constructors, agreed namespaces — or gets cleaned up later by linting and review. This is a "shift convention enforcement left" decision, not a feature decision.
• Build vs. buy vs. vendor. A concrete reference point in the stubs decision: adopt the opinionated third-party set, harvest its ideas into an internal stubs/ directory, or keep Laravel defaults. Because a bespoke stub set is roughly a 1–2 day task, the package's real value is as a head start and reference implementation, not a long-term dependency.
• Developer experience / onboarding roadmap item. Reduces "first PR" friction for new hires and contractors: fewer review comments on boilerplate, fewer convention docs to memorize, generated code that passes CI on the first attempt.
• Code review cost reduction. Reviewers spend attention on logic instead of strict_types, visibility modifiers, or return types. Measurable indirectly via review turnaround and PR comment volume on newly generated files.
• Greenfield vs. brownfield gating. Supports a decision on whether to standardize scaffolding tooling now (new services, new modules, new repos, the shared starter template) versus deferring for legacy codebases where conventions are already de facto settled and retrofit risk outweighs benefit.
• Explicitly not a customer-facing or runtime decision. Dev-only dependency: no effect on product capabilities, latency, SLAs, security posture, or deployment artifacts. Treat it as an engineering-enablement line item with a small timebox, not a roadmap feature. Do not let it consume roadmap capacity.

When to Consider This Package

Consider it when:

• You are standing up a new Laravel project, a new bounded context, or the shared starter template and want conventions baked in from commit one — the highest-leverage moment, since every downstream service inherits the output.
• The team has already agreed on the conventions this package encodes (strict types, final-by-default, the author's structural choices) — or you are explicitly willing to fork/vendor and edit.
• You want a cheap, reversible experiment: a dev-only dependency removable in one commit with zero runtime impact, evaluable in a half-day spike.
• You need a starting reference for building your own internal stub set rather than a supported dependency. The diff between its output and your current conventions is the deliverable.
• You want a low-cost conversation-forcing artifact — a published stub set turns an abstract "should we standardize scaffolding?" debate into a reviewable proposal for the standards owner.

Look elsewhere / skip when:

• Adoption signals matter to your risk model. Zero stars, zero dependents, score 0, single maintainer. Not evidence of bad code — JustSteveKing is a well-known Laravel contributor — but evidence of no external validation and no ecosystem pressure to track future Laravel majors. Verify Laravel/PHP version support before committing.
• Your conventions diverge from the author's opinions. At that point you are maintaining a fork, which is worse than owning your own stubs outright.
• You already enforce conventions via Pint, PHPStan/Larastan, Rector, or a custom ruleset. Adding stub overrides risks a second, silent source of truth.
• You need runtime behavior or generators. This package does nothing at runtime and generates no domain code. If the requirement is API resources, DTOs, or domain model generation, look at dedicated generator packages.
• Other stub-publishing packages are in play. Stub resolution order and publish conflicts cause "why did my model generate wrong?" bugs that are slow to diagnose and erode trust in the scaffolder.
• Stub filenames drift from the framework skeleton. A mismatched name is silently ignored — the framework default is used instead — so the failure mode is quiet divergence, not a build break.

How to Pitch It (Stakeholders)

To executives: A near-zero-risk developer tooling experiment that makes newly generated code consistent from day one. No customer impact, no infrastructure cost, no runtime footprint, reversible in a single commit. Total cost is roughly a day of engineering time. Recommend framing as evaluate, not adopt — the project has essentially no community traction, so we should not depend on it long-term. Upside is modest but real: less review churn and faster onboarding on every new Laravel service.

To engineering leadership: It is an opinionated drop-in replacement for Laravel's default Artisan stubs, so make:* commands emit code that already matches a strict, modern PHP style. The strategic value is not the package — it is the pattern: owning your scaffolding. Recommended path is a timeboxed spike (half day): install, stub:publish, generate a representative sample, diff against our conventions. Then either keep it or lift the good parts into an internal stubs/ directory we control and remove the dependency. Owning ~15 template files costs little and eliminates single-maintainer, tag-deletion, and Laravel-upgrade risk entirely. Guardrails: pin the Laravel/PHP version, re-verify stub filenames on every major upgrade (a mismatched name is silently ignored — the most likely defect), assign an owner alongside Pint/PHPStan config, and add a CI check that a freshly generated artifact passes lint and static analysis so drift is loud rather than silent.

To the team: Try it on the next greenfield service, not mid-sprint on an existing repo. Read every stub before it touches your code — expect strict_types, final, promotion, readonly. If the generated code matches what you would have hand-written, keep it (vendored); if not, take the ideas and move on. Note in the README why our stubs differ from stock Laravel so newcomers don't copy conflicting tutorial patterns.