Package Wizard Laravel Package

Product Decisions This Supports

• Developer-experience (DX) investment sizing. This package is a concrete data point for the recurring "should we fund a golden path for package creation?" question. It quantifies what an out-of-the-box scaffold actually buys you: PSR-4 wiring, a registered service provider, config stub, directory layout, and a test harness — i.e., the ~30–60 minutes of copy-paste-and-fix that precedes every new package.
• Build vs. buy vs. template-repo. Package Wizard competes with three realistic alternatives: (a) a GitHub template repository, (b) composer init plus a handful of house scripts, and (c) a bespoke make:package Artisan command. Adopting this package is the "buy" option and should be evaluated explicitly against the other two, not treated as a default.
• Standardization and convention compliance. If the org ships multiple internal Laravel packages, inconsistent autoloading and service-provider registration are a real source of integration bugs. A scaffolder is a policy-enforcement mechanism: every new repo starts compliant, which reduces review load and post-merge cleanup.
• Onboarding and time-to-first-PR. For engineers authoring their first package, interactive prompts lower the ceiling on prerequisite knowledge. This supports decisions about whether to invest in onboarding assets versus documentation-only approaches.
• Scope clarification for the roadmap. This is a package authoring tool, not an application scaffolder. It does not overlap with the Laravel installer, Jetstream/Breeze, or app-level starters — worth stating plainly so it isn't mistakenly funded under an "app boilerplate" initiative.
• Vendor/dependency risk register entry. With 62 stars, a single maintainer, a last release of 2021-05-25, and an archived repository, this is a textbook "dev-only, low-blast-radius, but also low-support" dependency. The decision it drives is whether the org accepts unmaintained tooling in its developer toolchain at all.
• Fork-and-own decision. Because the surface area is small and MIT-licensed, "internalize the template" is a viable product decision: vendor the generated output conventions into your own skeleton repo and drop the tool dependency entirely.

When to Consider This Package

Consider it when:

• You are running a short, time-boxed evaluation of scaffolding approaches and want a working reference implementation to compare against, not a long-term dependency.
• Your toolchain is pinned to the Laravel 8 / PHP 7.4–8.0 era in which the package was last released, and you are not planning to move soon.
• You only ever invoke it manually, locally, as a developer convenience — never in CI, never as a Composer dependency of anything that ships, never as a required step in a documented workflow.
• You want the output more than the tool: the generated skeleton is a useful, concrete artifact you can study and copy into an internal template.
• You have a single-maintainer-tolerance policy for dev-only tooling and accept that fixes will be yours to write.

Look elsewhere when:

• You are on PHP 8.2+ / Laravel 10–12. An archived 2021 scaffolder will emit composer.json constraints, service-provider signatures, and test bootstrap conventions that are at best stale and at worst broken against your runtime. Verify generation output against your actual CI before trusting it.
• You need non-interactive, scriptable generation (CI, monorepo automation, --no-interaction flows). Interactive prompt tools are a poor fit for automation by design.
• You need maintenance guarantees, security response, or issue triage — an archived repo offers none of these. Treat any bug as permanent.
• You want team-wide policy enforcement. A tool you cannot patch is not a policy mechanism; a template repository you own is.
• Preferred alternatives:
  • spatie/package-skeleton-laravel — the de facto community skeleton, actively maintained, and the strongest direct substitute.
  • A GitHub template repository you control — best fit for org-wide conventions and versioned alongside your standards.
  • An internal make:package Artisan/Composer script — best when you need automation, non-interactive flags, and CI integration.
  • composer init + orchestra/testbench — minimal, fully maintained, zero third-party scaffolding risk.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed developer convenience that removes repetitive boilerplate when engineers create new Laravel packages. It is not customer-facing and carries no runtime or data risk — at worst it wastes a few hours of an engineer's time. The catch is that the project has been archived since 2021, has very limited adoption (~62 stars), and receives no updates. Recommendation: do not adopt as a standing dependency. If package-creation consistency matters to the roadmap, fund a small internal template repository or a make:package command instead — same benefit, fully under our control, and maintainable against current Laravel versions.

To engineering: The feature set is genuinely useful and the design is sound — guided prompts, correct PSR-4, auto-registered service provider, config stub, test setup. It solves a real, recurring annoyance. But it was last released in May 2021 and is archived, so expect stale composer.json constraints, outdated service-provider conventions, and no upstream fixes. Proposed path: use it as a reference design for one sprint, harvest the generated output into an internally owned skeleton repo (or a spatie/package-skeleton-laravel fork), and standardize on that. If anyone wants to trial it locally first, keep it strictly as a dev-time tool, verify output against our CI matrix, and do not add it to any shared toolchain or pipeline.