Laravel Installer Laravel Package

Product Decisions This Supports

• Framework upgrade policy becomes a product choice, not a tooling constraint. Release 1.6.0 lets projects be created against any Laravel version Composer can resolve, so the decision "do we adopt the next Laravel major?" is no longer gated by whether our project generator supports it. Roadmap items that were effectively blocked on scaffolder work can be re-sequenced.
• Multi-version portfolio support. If we ship templates, starter kits, SDKs, or self-hosted installs that must run on more than one Laravel major, this lets a single generator serve the whole supported matrix instead of maintaining a fork per version. That is a build-vs-buy argument in favor of buying/adopting rather than maintaining bespoke template repos.
• Golden-path standardization. One blessed way to bootstrap a project, with Composer as the source of truth for framework versions. Reduces drift between teams and makes onboarding documentation stable across Laravel releases.
• Time-to-first-commit as a product metric. New services, pilots, and client engagements start from a generated skeleton rather than a hand-assembled repo. Worth instrumenting if we adopt it.
• Risk rebalancing, not risk elimination. The package no longer decides our Laravel version for us — we do. That removes an upstream dependency risk but transfers an obligation: we now own the compatibility test matrix across the versions we claim to support.
• Caveat for the roadmap. Because version resolution is now permissive, generated projects can silently pick up newer Laravel minors. Any adoption decision should pair this with a policy of committing composer.lock in generated scaffolds and testing against both the lowest and highest supported versions.

When to Consider This Package

Consider it when:

• We create Laravel projects repeatedly — several per quarter, across multiple teams, or as part of client delivery.
• We must support more than one Laravel major simultaneously (agency work, plugin/package vendors, platforms with customer-hosted deployments).
• We already maintain a custom "laravel new"-style wrapper or template repo that hardcodes a framework version and costs engineering time at every Laravel release.
• We want the dependency manager, not our tooling, to be the authority on which framework versions are permitted.
• We are piloting a new Laravel major and want new projects on it while existing projects stay put — without forking the generator.

Look elsewhere when:

• We scaffold rarely (one or two apps, infrequent rebuilds) — the coordination cost outweighs the benefit.
• Our real scaffolding needs are organizational (CI pipelines, IaC, SSO, observability defaults) that this package does not cover; it would be one layer among several.
• We require vendor-supported LTS guarantees, an SLA, or a commercial support contract.
• We need fully deterministic, air-gapped, byte-identical output — "any Composer-supported version" is the opposite of a pinned, reproducible artifact unless we add our own locking and mirroring.
• The team is standardized on a single Laravel version with no near-term upgrade plans; adopt later when the matrix actually widens.

How to Pitch It (Stakeholders)

For executives (one paragraph): Every Laravel major release has historically created a small but recurring tax — our project generator had to be updated before teams could start new work on the new version. Release 1.6.0 removes that coupling: the generator now defers to Composer, so adopting a new Laravel version is a configuration decision rather than an engineering project. The practical value is faster starts for new products, one generator instead of several version-specific templates, and less exposure to running unsupported framework versions for security patching. It is a low-risk, non-breaking change that only widens what the tool accepts.

For engineering leads: One scaffolder for all supported Laravel majors; no more forking templates per version; upgrade pilots are unblocked because new projects can target the new major while existing services stay put. Two conditions of adoption: we own the compatibility test matrix, so add CI jobs that scaffold against both the lowest and highest Laravel versions we claim to support; and generated projects must commit composer.lock so permissive version resolution cannot drift underneath us.

The ask: Approve a low-risk trial on the next two new projects. Success measures: reduced time from kickoff to first deployable commit, number of bespoke template repos retired, and number of Laravel majors supported without any tooling change. Revisit for broader rollout after one full Laravel release cycle.