Laravel Package Generator Laravel Package

Product Decisions This Supports

• Build vs. buy vs. fork, decided cheaply. This package forces an explicit choice between three options: adopt the generator as-is, fork its stubs and wrap the command in an internal script, or standardize on spatie/package-skeleton-laravel / an existing template repo. Because the output is ordinary Laravel code with no runtime dependency on the generator, this is a one-to-two-engineer-day spike with a near-zero reversal cost — not a procurement or architecture review cycle. Make the call and move on.
• Standardizing package anatomy across squads. One command emits composer.json, service provider, publishable config, migrations, routes, views, and translations. That gives every team the same canonical shape, which directly reduces the "every package looks different" tax paid in code review, security review, and platform ownership. The measurable outcome is fewer review comments per new package and fewer bespoke conventions to document.
• Onboarding and modularization velocity. It shortens time-to-first-package for new hires and makes it cheap to prototype a package boundary before committing to a monorepo split or extracting a module out of the monolith. Value is hours saved per package multiplied by packages per quarter — the pilot must produce that number before rollout.
• Roadmap input for the internal developer platform. The prompts the tool exposes — vendor/namespace, Filament admin, API routes, translations, assets — are a useful proxy for which scaffolding knobs teams actually care about. Feed that list into your own golden-path template even if you never adopt the tool.
• Vendor and dependency policy evidence. Since the generator never ships at runtime, blast radius is near zero. That is a concrete, defensible data point for a permissive policy on low-maturity dev-time tooling, distinct from the stricter bar applied to runtime dependencies. Use it to keep the two policies from collapsing into one.
• Package-sprawl governance. Cheap package creation has a real cost: more artifacts for the platform team to support. Pair adoption with a single sanctioned stub set and a lightweight conformance check in package CI (namespace policy, PHP/Laravel version floor, static analysis level, license header) rather than letting each squad generate its own dialect.
• Explicitly not a product differentiator. No user-facing capability, no revenue lever, no runtime footprint, no SLA surface. Budget it as internal developer-productivity spend only — never as a roadmap line item, and keep it out of customer-facing or platform-strategy narratives.

When to Consider This Package

Adopt or pilot it when:

• Teams create Laravel packages repeatedly — roughly several per quarter — and the boilerplate is a measurable, recurring drag rather than a hypothetical one.
• You want an interactive wizard covering common Laravel/Filament/API layouts without authoring and maintaining a skeleton from scratch.
• Scope is strictly developer workstations or CI scaffolding. Never a production or runtime dependency: install globally or under require-dev, and keep it out of both the app lockfile and the generated package's require-dev.
• You accept that you are adopting a hobby project — 8 stars, 0 dependents, a single maintainer, last release 2024-10-26 — and are prepared to fork, pin an exact version, and own the stubs. Assign a named internal owner (platform or developer experience) before rollout, because when a scaffolded package misbehaves the complaint lands on the tool.
• You have already validated generated output against real internal conventions — Pint/PHPStan/Pest, PHP and Laravel version floors, namespace layout, CI provider — and the resulting diff is small enough that editing beats hand-writing.

Look elsewhere when:

• You need a supported, battle-tested baseline. spatie/package-skeleton-laravel with spatie/laravel-package-tools and orchestra/testbench remains the de facto community standard, with far more usage and review surface.
• Your org already has an internal starter kit or monorepo template. Improving one source of truth beats layering a second, competing one — two templates means two conventions and permanent drift.
• You need guarantees: security review, SLA, long-term maintenance, or vendor accountability. There is no community backstop here; your own review is the only quality gate.
• Your monorepo layout or tooling is non-idiomatic and the generator can't model it.
• Compliance requirements — license headers, SBOM, dependency allowlists — would force you to rewrite the templates anyway, erasing the savings.
• You don't run the TomatoPHP/Filament stack and the prune list is long enough that hand-writing is comparable work.

Hard gate before adoption: generate two to three representative packages, run them unmodified through your pipeline (composer validate --strict, Pint, PHPStan, Pest/testbench), and diff the output against internal standards. That diff plus one real release cycle of evidence is the entire decision input. Small diff → fork the stubs or wrap the command in an internal make:package script. Large diff → treat the exercise as a written specification for a homegrown template and decline the dependency. Do not publish internal guidance until a pilot package ships an actual release — generators that look fine after composer install can still be wrong about tagging, changelogs, and CI on the second commit.

How to Pitch It (Stakeholders)

To executives: This is a small, reversible developer-productivity experiment, not a platform bet. It automates the boilerplate that stands between a team and a working Laravel package — provider, config, migrations, routes, composer metadata — and it never runs in production, so there is no customer-facing risk and no change to our runtime dependency graph. Cost is a short spike plus a few hours per Laravel major to keep forked templates current; the return is hours saved per package created, multiplied by how many packages we spin up per quarter. Approve it as a pilot with a defined gate and a named owner, and expect a go/no-go decision within one release cycle.

To engineering leadership: The realistic plan is not "use the vendor command." It is: fork the stubs, encode our conventions in the fork, and expose a single internal make:package script that runs generation plus license headers, version floors, Pint/PHPStan/Rector configs, CI workflow, and README/CHANGELOG templates in one shot. That wrapper becomes the thing onboarding docs reference; the generator becomes an implementation detail we can swap or abandon without touching a single generated package.

To engineering teams: You get a working package skeleton in seconds instead of an afternoon of copying files, and every package you scaffold looks like every other package — which is what makes review fast and extraction to a monorepo boring. The trade-off is honest: you'll still do a human pass on the service provider, migration timestamps, config keys, and test harness, and if the output drifts from our standards the fix goes in the fork, not in your package.

To security and compliance: Dev-time tool only, MIT-licensed, installed globally or under require-dev, never published into a package we ship. Output is first-party code we review and own; the generator has no runtime presence and adds nothing to a consumer's dependency graph. Known maturity risk — single maintainer, low adoption — is mitigated by forking and pinning an exact version rather than by a vendor relationship.

What to say if we decline: The evaluation still pays for itself. The prompts this tool exposes and the diff against our conventions become the specification for our own template repo, and we walk away with a better internal golden path and a written record of why we didn't take the dependency.