Installer Laravel Package

Technical Evaluation

Architecture fit laravel/installer is not a library you integrate — it is a globally installed Composer CLI (composer global require laravel/installer) built on Symfony Console, exposing laravel new and, since v5.31.0, laravel package. Its job is orchestration: fetch the laravel/laravel skeleton, run composer install, select a starter kit (React/Vue/Livewire/Svelte), run a Node install/build, optionally install Laravel Boost, and emit next-step guidance. Fit is therefore at the developer-environment and platform-tooling layer, not the application runtime. The dependents: 0 figure is expected rather than alarming — nothing requires a CLI tool — but it also confirms there is no embedding path. Any programmatic use means shelling out and parsing output or exit codes.

Integration feasibility — high, but only for a narrow scope. Two changelog items make automation realistic:

• v5.27.0 added structured JSON output when invoked by AI agents, giving a machine-readable contract instead of screen-scraping ASCII banners.
• v5.28.x–v5.29.x fixed --no-interaction TTY attachment for child processes, which is the classic cause of hung CI jobs.
• Scoping flags (--no-node, --no-boost, package-manager selection, --no-interaction) let you constrain the blast radius per environment.

The honest read on the opportunity: 35.3 score: the installer adds onboarding DX and starter-kit glue, but almost nothing it does is unavailable via composer create-project laravel/laravel plus your own bootstrap script. Its value is convention and prompt-driven ergonomics, not unique capability.

Technical risk

• Supply chain. Starter-kit installer hooks (v5.28.0) execute code sourced from third-party starter-kit repositories. v5.25.2 explicitly "prevents installed package from executing malicious code via postinstall" — a signal that this surface has been actively exploited or abused.
• Self-update behaviour. The installer can update itself; v5.32.0 shipped a fix for an installer self-update loop. In CI this is a reproducibility hazard, not a convenience.
• Network-time coupling. Skeleton, Composer packages, npm packages, and Boost are all fetched at run time, so a "successful" scaffold depends on four external registries.
• Release churn with regressions. The changelog shows reverts (PR #565 reverted by #566), reverted credential handling (#520 → #521), and PHP fatal errors fixed in laravel new (#567). Unpinned use is a moving target.
• Windows parity. TTY/stdin handling, queue:listen timeouts, caret-quoting in Boost version constraints, path handling — a disproportionate share of defects are Windows-specific.

Key questions

1. Are we standardizing on one starter kit, or leaving kit choice to teams? This determines whether hooks run at all.
2. Do we permit starter-kit installer hooks to execute unreviewed third-party code on developer machines and in CI?
3. Is the installer the system of record for project creation, or an exploration convenience in front of a reviewed internal template repo?
4. What is the pinned version, and who owns the review cadence against the changelog?
5. Do we need laravel package for internal package scaffolding, and does that change our monorepo conventions?
6. Is the JSON output mode stable enough to build an internal wrapper on, or should we treat it as best-effort?

Integration Approach

Stack fit Target the developer-environment layer: PHP 8.2+ with Composer 2 on host machines, or a devcontainer/dev image that bakes in a pinned installer. Node is optional via --no-node; Bun is supported as a first-class package manager (v5.20.0, bunx equivalent in v5.22.0). If your CI images are Linux-only, most of the Windows-specific defect class disappears — but your developers' laptops will not be.

Migration path Two viable paths, and the choice is strategic rather than technical:

• Adopt as front door (low effort): document laravel new with a fixed flag set, pin the version, and let it scaffold. Fastest to value; weakest reproducibility.
• Adopt as exploration only (recommended): keep a reviewed internal template repository as the system of record for new services, and position the installer as the way engineers prototype or evaluate starter kits. This preserves the DX win while keeping supply-chain exposure out of anything that reaches production.

There is no meaningful migration burden either way — the installer leaves no runtime artifact in the resulting application.

Compatibility Version 5.x tracks current Laravel: Laravel 13.x compatibility landed in v5.24.7, PHP 8.5 compatibility in v5.23.1, Symfony 8 constraints allowed in v5.27.0. Pin to an exact 5.x tag per quarter and re-validate on Laravel major/minor releases. Note that the installer's PHP requirement is a floor on developer machines, which will be a support topic wherever multiple PHP versions coexist.

Sequencing

1. Pin an exact version in the dev image / onboarding doc; disable self-update.
2. Write a thin internal wrapper (or Makefile target) that fixes the flag set, forces --no-interaction in CI, and captures JSON output.
3. Pilot with one team for two weeks; log every prompt, failure, and manual workaround.
4. Publish a starter-kit policy: which kits are approved, whether hooks may run, what Boost/--no-boost default applies.
5. Add a CI smoke job that scaffolds a throwaway app nightly, so registry or version drift surfaces before a new hire hits it.

Operational Impact

Maintenance Low absolute cost, non-zero ownership. The real ongoing task is changelog review against a pinned version — the release cadence is weekly-ish and includes behavioural fixes that silently change scaffolding output. Budget roughly an hour per month, plus a re-pin and smoke-test on each Laravel minor.

Support Support load sits with developer onboarding, not on-call. Expect recurring tickets on: PHP version mismatch, missing Node/Bun, interactive prompts hanging in non-TTY contexts, and Windows path or stdin failures. Documenting a single canonical command eliminates most of it. No production incident surface exists.

Scaling Trivially scalable — there is no runtime component and no per-request cost. The scaling constraints are mundane: npm/Composer registry throughput and CI minutes when scaffolding is exercised in pipelines. Keep CI scaffolding to a single nightly smoke job rather than per-PR.

Failure modes

• Prompt hangs in CI from missing TTY / ignored --no-interaction.
• Self-update loop or unexpected version drift mid-run.
• Third-party starter-kit hook failure or malicious postinstall execution.
• Boost install failures from version-constraint quoting, particularly on Windows.
• Node build timeouts or absent package manager, resolved by --no-node.
• Partial scaffolds that leave a broken directory and unclear resumption guidance.

Ramp-up Hours, not days. Any PHP developer can use it immediately; the effort is in the wrapper, the pinning policy, and the starter-kit governance decision — roughly one engineer-week end to end, dominated by the policy conversation rather than the tooling.