Laravel Installer Laravel Package

Getting Started

This package scaffolds Laravel projects, so it sits at the very front of your workflow rather than inside an existing app. Install it globally (or as a dev dependency in a monorepo tooling package):

composer global require <vendor>/<package>

Then publish/scan the config if the package ships one:

php <vendor>/<package>/bin/<binary> config:publish   # or `php artisan vendor:publish --tag=<package>-config`

Where to look first, in order:

1. The README's usage block for the exact command signature and options — do this before reading source.
2. composer.json of the package — check the require block for laravel/framework and php constraints. As of 1.6.0 there is no fixed Laravel version allow-list, so this file is now your source of truth for the floor, not the ceiling.
3. config/<package>.php (if present) for default Laravel version, stub paths, and post-install hooks.
4. src/Console/ for the command implementation — useful when you need to know the order of Composer calls and file mutations.

First use case: creating a project pinned to the Laravel version your organisation standardises on.

# Scaffold a new app on a specific supported Laravel line
<binary> new my-app --laravel="^11.0"

# Or let Composer resolve the newest version your PHP platform allows
<binary> new my-app

Because 1.6.0 defers version selection to Composer, the second form is now genuinely "latest your platform supports" rather than "latest the package knows about."

Implementation Patterns

Pin the version explicitly, always. The headline change in 1.6.0 means the package will happily pass through any constraint Composer can resolve. That is flexibility, but it makes builds non-deterministic by default. Pass an explicit constraint in every scripted invocation:

<binary> new "$APP_NAME" --laravel="^10.48"

CI matrix scaffolding. Combine the Composer-resolved version with your test matrix so you validate the exact skeleton you ship:

strategy:
  matrix:
    laravel: ["^10.48", "^11.0", "^12.0"]
steps:
  - run: <binary> new app --laravel="${{ matrix.laravel }}" --no-interaction
  - run: cd app && composer test

Expect older matrix entries to fail on newer PHP runners; that is a platform constraint, not a package bug (see Gotchas).

Wrap it in your own Composer script so app creation and your house standards (pint config, CI skeleton, .editorconfig, base test suite) happen in one step:

{
  "scripts": {
    "new-app": [
      "@php <binary> new app --laravel=^11.0",
      "cp -r stubs/. app/",
      "cd app && composer install && ./vendor/bin/pint"
    ]
  }
}

Keep stubs in version control, not in the package. If you customise the generated skeleton, copy the stubs out into your own repo and point the config's stub path at them. Stubs bundled with the package will drift with every release, and you do not want a patch release rewriting your Dockerfile.

Prefer the package over raw composer create-project when you need post-install mutation: env generation, key generation, database choice, starter-kit wiring, or removing the default README. When you only need the untouched skeleton, composer create-project laravel/laravel is fewer moving parts.

Programmatic use. If the scaffolder exposes a class rather than only a console command, call it from your own Artisan command so internal tooling can generate apps from a template registry:

Scaffolder::make()
    ->path($target)
    ->laravelVersion('^11.0')
    ->withOptions($options)
    ->create();

Gotchas and Tips

"Any Laravel version supported by Composer" is not "any Laravel version." Composer still enforces the chosen laravel/framework version's own php and extension constraints. Scaffolding Laravel 10 onto a PHP 8.3-only runner will fail at composer install time with a platform error, not a scaffolder error. Check php -v before assuming the release broke something.

Interactive prompts break CI. Without --no-interaction, the command will block waiting on a starter-kit or database prompt and your pipeline will hang until timeout. Always pass the non-interactive flag and every option explicitly.

Constraint syntax matters. --laravel=11 may be normalised to ^11.0 or rejected outright depending on the package's parsing. Use a full Composer constraint (^11.0, 11.*, 11.35.0) and verify against the generated composer.json rather than trusting the CLI echo.

No lock file at scaffold time. The scaffolder produces a composer.json and then installs; you get whatever the resolver picks that day. If reproducibility matters, commit the generated composer.lock immediately and treat it as part of the template.

Composer cache and minimum-stability. Setups that work locally can fail on a clean CI runner because of minimum-stability/prefer-stable differences or a stale Composer cache serving an old package index. Reproduce failures with:

COMPOSER_CACHE_DIR=/tmp/empty-cache <binary> new app --laravel="^11.0" -vvv

Private repositories and auth. If your stub or post-install step pulls from a private VCS, the scaffolder inherits the ambient Composer credentials. On CI that means COMPOSER_AUTH must be set before the scaffold runs, or the install step fails halfway through with a partial directory left behind.

Failed scaffolds leave dirty directories. Most implementations do not clean up on failure. Always delete the target path before retrying, otherwise you get "directory not empty" or, worse, a half-scaffolded app that appears to boot.

Debugging: run the command with -vvv first — the ordering of generated-file writes vs. Composer invocations is where most surprises live. If the output looks right but the app will not boot, diff the generated composer.json against laravel/laravel at the same tag; the delta is almost always a missing post-autoload-dump script or a stale config/app.php.

Extension points to favour: stub path override and post-create hooks. Both are stable across minor releases. Avoid subclassing the scaffolder class itself — the 1.6.0 change shows version resolution is an actively moving part of the implementation.