Laravel Make Extender Laravel Package

Product Decisions This Supports

• Cycle-time investment: boilerplate generation for Helpers, Scopes, Services, Traits, Casts, Collection Macros, and View Composers is pure tax on feature delivery. This package converts a recurring 10–30 minute "where does this file go, and what's the stub?" task into a single artisan command — a direct lever on lead time per feature.
• Architecture standardization (build vs. buy): the alternative is hand-rolling a stub directory plus custom make: commands internally (roughly 1–3 days of senior engineering time, then permanent ownership). Buying means adopting a 36-star, single-maintainer MIT package. This is a genuine trade-off decision worth an explicit call, not a default.
• Enforcing a house style: because the package emits files into predictable namespaces, it becomes an opinionated record of where services, scopes, and macros live. That's useful if the roadmap includes introducing a service layer, taming fat controllers, or migrating toward a DDD-lite structure — the generator makes the target architecture the path of least resistance.
• Roadmap signal for refactors: if the next two quarters include "reduce controller size," "extract query scopes," or "standardize macro usage," this is a cheap enabler that pairs with that work rather than a standalone initiative.
• Onboarding economics: new hires and contractors get correct, convention-compliant files on day one instead of copying from a neighbor's PR. Measurable via time-to-first-merged-PR and review-comment volume on structural issues.
• Use cases that justify it most: teams building multiple Laravel apps from a shared template, platform teams supporting several product squads, or any codebase where "add a query scope" currently means copy-paste from an unrelated model.

When to Consider This Package

Consider adopting when:

• You're on a supported Laravel version and generate classes via artisan on a regular basis (daily or weekly, not monthly).
• You have a team of three or more developers, or contractors who rotate in — convention drift is the actual cost being solved, and it scales with headcount.
• Your architecture already (or imminently) uses services, query scopes, custom casts, collection macros, or view composers as first-class concepts. Generating files for patterns you don't use is noise.
• You're greenfield or mid-refactor and can set the convention now rather than retrofit it.
• You're comfortable treating it as vendored/forkable source: it's MIT, it's a dev-time tool, and the blast radius of abandonment is a broken composer require --dev at some future upgrade — not a production outage.

Look elsewhere when:

• You're a solo developer or a one-off prototype; copying a stub is cheaper than adding a dependency.
• You require vendor SLAs, security review of every dependency, or a maintained support channel. One maintainer and 36 stars does not clear a typical enterprise procurement bar — plan to fork and own it, or skip it.
• Your team has already standardized on an alternative generator ecosystem, or has internal Laravel skeleton/stub tooling that would now overlap and confuse.
• The Laravel major version you're targeting isn't yet validated against the package; the release cadence (most recent 2025-08-21) means you should verify compatibility in a spike before committing.
• You need generators for patterns outside its scope (repositories, actions, DTOs, policies) — evaluate whether a partial fit is worth the inconsistency of two competing conventions.

Mitigation if you adopt: pin the version, keep it in require-dev, fork it into your org for anything load-bearing, and re-evaluate at each Laravel major upgrade. Treat the generated stubs as your code and tune them.

How to Pitch It (Stakeholders)

To executives (30 seconds): This is a small developer-productivity tool that removes repetitive scaffolding work in our Laravel codebase and, more importantly, makes our architectural conventions the default rather than something we enforce in code review. Cost is effectively zero — MIT licensed, development-only, no runtime footprint in production. The realistic benefit is faster feature delivery and cheaper onboarding; the realistic risk is that it's a tiny open-source project with one maintainer, which we neutralize by pinning the version and forking it if it ever becomes load-bearing. Recommendation: pilot on one squad for a sprint, measure, then decide.

To engineering leadership: The package extends artisan make: to cover the extension points Laravel doesn't ship generators for — Services, Builder Scopes, custom Casts, Collection Macros, View Composers, Traits, and Helpers. It standardizes file location and stub content, which reduces review friction and stops the copy-paste-from-a-random-model pattern. It's dev-only and trivially removable. The honest caveats: 36 stars, one maintainer, no support guarantee — so we vendor the stubs rather than treat it as infrastructure. Ask engineering for a one-sprint spike: install, add our house conventions to the stubs, and report time saved per feature and any friction. Success looks like fewer structural review comments and a measurable drop in scaffolding time; failure looks like fighting the generators or Laravel version incompatibility, in which case we fork the stubs and drop the dependency.