skip to content

How do you create a Laravel app from a community starter kit with the installer's --using option, and what must such a kit provide?

level: middleimportance: nice to knowfreq 14%

answer

  1. any Packagist project package
  2. create-project under the hood
  3. a git URL goes through tiged
  4. .env.example lists required variables
  5. post-create-project-cmd for setup

basics

~10 s

Run laravel new my-app --using=vendor/package; the installer runs composer create-project on that Packagist package instead of laravel/laravel. The kit must declare its environment variables in .env.example and its setup steps in composer.json's post-create-project-cmd.

solid answer

~40 s

`laravel new my-app --using=example/starter-kit` makes the installer run `composer create-project example/starter-kit my-app --stability=dev` in place of the default skeleton, then carry on with its usual steps: key generation, the `APP_URL` rewrite and the database prompts. If the value contains `://`, the installer treats it as a repository URL and clones it with `npx tiged` followed by `composer install`. Laravel's own kit-specific flags such as `--workos` and `--teams` only apply to the first-party kits. To publish a kit, you put it on Packagist as a project, list every required variable in `.env.example`, and put post-install commands in the `post-create-project-cmd` array of its `composer.json`.

code

bash · 5 lines
bash
# a kit published on Packagist
laravel new my-app --using=example/starter-kit

# a repository URL is cloned with tiged, then composer install
laravel new my-app --using=https://github.com/example/starter-kit

go deeper

for a junior

Remember the command: laravel new my-app --using=vendor/package creates the app from that package.

for a middle

Explain the create-project swap, the tiged path for URLs, and the .env.example and post-create-project-cmd requirements.

for a senior

Vet a community kit like adopted code: pinned majors, auth implementation, license and maintenance, since no fixes arrive later.

for a principal

Consider publishing an internal kit as the organisation's standard starting point, and budget for keeping that template current.

## What `--using` is for The four first-party kits cover React, Vue, Svelte and Livewire with Fortify or WorkOS. Community kits cover everything else: other UI libraries, admin-panel starters, multi-tenant templates, a company's internal standard app. The installer's `--using` option lets `laravel new` create an app from any of them without changing your workflow. ```bash laravel new my-app --using=example/starter-kit ``` ## What the installer does with it 1. **Picks the source.** The value of `--using` becomes the "starter kit" in place of `laravel/laravel` (the same slot `--react` or `--livewire` would fill with a first-party kit). 2. **Creates the project.** For a package name it runs `composer create-project example/starter-kit my-app --stability=dev`. 3. **Handles URLs.** If the value contains `://`, the installer assumes a repository URL and instead runs `npx tiged@latest <url> my-app`, then `composer install` inside it. 4. **Runs the usual initialisation**: the kit's Composer scripts, `php artisan key:generate`, setting `APP_URL` from the project name, and the database and migration prompts. 5. **Runs installer hooks** if the kit declares any under `extra.laravel.installer.post-create-project` in its `composer.json` — the mechanism the first-party kits use for `php artisan install:features`. Two consequences: - **The same ownership model applies.** Like the official kits, a community kit is copied into your repository once; its later releases do not reach your app. - **First-party variant flags do not apply.** `--workos` and `--teams` switch the official kits to other branches; with `--using`, the installer creates exactly the package you named. ## Building a kit others can use The docs set two requirements beyond "publish it on Packagist": - **`.env.example` must declare every environment variable the kit needs**, because the new app's `.env` is created from it. - **Post-installation commands go in `post-create-project-cmd`** in the kit's `composer.json` — for example generating the key, creating the SQLite file and running migrations, which is exactly what the official kits list there. Practical additions: | Concern | How a good kit handles it | |---|---| | Package type | `"type": "project"` so Composer treats it as an application template | | Front-end build | a working `package.json` with `dev` and `build` scripts | | Framework constraint | a current `laravel/framework` range, e.g. `^13.0` | | Tests | a passing suite, so users know the starting point is green | | Documentation | what it contains and what the user should delete | ## Evaluating a community kit Because you inherit every file, treat a community kit as code you are adopting, not a dependency you can swap later: 1. Check which Laravel, Inertia or Livewire majors it pins — an old kit starts you behind, just as Breeze would. 2. Read how authentication is done; a kit with home-grown login code deserves the same review as your own. 3. Check the license and whether it pulls in paid components. 4. Look at recent maintenance; you will not receive fixes, but an active project is a better reference for porting them. ## Where `--using` sits among the installer's choices | You want | Command | |---|---| | plain skeleton, no front-end kit | `laravel new my-app` and choose none | | a first-party kit | `laravel new my-app --react` (or `--vue`, `--svelte`, `--livewire`) | | a first-party kit variant | add `--workos`, `--teams` or `--no-authentication` | | a community kit on Packagist | `laravel new my-app --using=vendor/package` | | a kit from a repository URL | `laravel new my-app --using=https://…` | Everything after creation — key generation, `APP_URL`, database setup — is the same in every row, which is why a well-built community kit feels like a first-party one to its users. ## Summary for an interview `--using` swaps the package `composer create-project` starts from; a URL is cloned instead. The kit provides `.env.example` and `post-create-project-cmd`, and once created, it is your code.

  • Does laravel new --using=example/kit --workos give you a WorkOS version of the community kit?
    No. The installer only maps `--workos` and `--teams` to branches of Laravel's own kits (`dev-workos`, `dev-teams`, `dev-workos-teams`). With `--using`, it runs `composer create-project` on exactly the package you named, so any SSO support has to come from that kit itself.

saying these in an interview costs you the question

  • --using adds the community kit to an existing app with composer require
  • Community kits receive updates automatically after installation
  • A kit declares its required variables in config/app.php rather than .env.example
  • --using only accepts kits published by the Laravel organisation