skip to content

With the Laravel 13 installer, what does `laravel new` choose by default for testing, database, Boost and npm, and which flags change each?

level: middleimportance: should knowfreq 30%

answer

  1. choices pre-set before any prompt
  2. Pest unless --phpunit
  3. SQLite unless --database=
  4. Boost unless --no-boost
  5. npm unless --pnpm, --bun, --yarn, --no-node

basics

~10 s

The Laravel 13 installer defaults to Pest, SQLite, Laravel Boost and npm. Override them with --phpunit, --database=mysql (or mariadb, pgsql, sqlsrv), --no-boost, and --pnpm, --bun, --yarn or --no-node.

solid answer

~40 s

In installer v5.32, `laravel new` sets four choices before it shows any prompt: the test framework is **Pest** unless you pass `--phpunit`; the database is **SQLite** unless you pass `--database=` with `mysql`, `mariadb`, `pgsql` or `sqlsrv`; **Laravel Boost** is installed unless you pass `--no-boost`; and front-end dependencies are installed and built with **npm** unless you pass `--pnpm`, `--bun`, `--yarn` or `--no-node`. The prompts left are the project name and the starter-kit questions, where "Do you want to use a starter kit?" defaults to no. For a non-SQLite driver the installer uncomments the `DB_*` lines in `.env`, sets `DB_DATABASE` from the app name and migrates, so the database server must be reachable. An invalid `--database` value stops the run with an `InvalidArgumentException`.

code

bash · 5 lines
bash
# Team standard for the clinic app: PHPUnit, PostgreSQL, pnpm, no Boost
laravel new vet-clinic --phpunit --database=pgsql --pnpm --no-boost --git

# Everything default: Pest, SQLite, npm, Boost
laravel new vet-clinic-sandbox

go deeper

for a junior

Remember the defaults (Pest, SQLite, Boost, npm) and the flag that flips each one, starting with --phpunit and --database.

for a middle

Explain that the installer pre-sets these options before its prompts, how it rewrites the DB_ lines for a non-SQLite driver, and that the migration then needs a live server.

for a senior

Turn the defaults into a written, flag-complete install command so every new service and laptop gets the same test runner, driver and package manager.

for a principal

Weigh whether installer defaults such as Boost or Pest should be team policy, and record the decision so new projects do not drift apart.

## Why the defaults matter The **Laravel installer** (`laravel new`) is how most developers start a Laravel 13 app, and its defaults decide what the team inherits: which test runner every test is written for, which database the first migrations hit, and whether AI-agent tooling is committed to the repository. Interviewers ask about them because a new hire who accepts every default on a veterinary-clinic booking app may end up with a different stack than the rest of the team. ## The four pre-set choices In installer v5.32 the command sets these options *before* the interactive form runs, so they are not questions you answer. You change them with flags: | Choice | Default | Flag to change it | |---|---|---| | Test framework | Pest | `--phpunit` | | Database driver | SQLite | `--database=mysql`, `mariadb`, `pgsql` or `sqlsrv` | | Laravel Boost | Installed | `--no-boost` | | Node package manager | npm | `--pnpm`, `--bun`, `--yarn`, or `--no-node` to skip | Other useful flags: `--git` initializes a repository, `--github` also creates one on GitHub, `--force` overwrites an existing directory (refused when the target is `.`), `--dev` installs the development branch, and `--using=vendor/package` starts from a community starter kit. ## What each default actually does 1. **Pest.** The skeleton itself ships PHPUnit. The installer removes `phpunit/phpunit`, requires `pestphp/pest` and `pestphp/pest-plugin-laravel`, runs `pest --init`, then temporarily installs Pest's drift plugin to convert the example tests to Pest syntax and removes it again. 2. **SQLite.** The installer writes `DB_CONNECTION=sqlite`, keeps the host, port and credential lines commented out, creates `database/database.sqlite` and runs `php artisan migrate`. 3. **Another driver.** With `--database=pgsql` it uncomments the `DB_*` lines in both `.env` and `.env.example`, sets `DB_PORT` to 5432 (1433 for `sqlsrv`, 3306 otherwise) and sets `DB_DATABASE` to the app name, lowercased, with dashes turned into underscores. It then migrates, so a server that is not running shows up as a failed migration step. 4. **Boost** adds the `laravel/boost` dev package and its agent guidelines. 5. **npm** runs install and build so the first page load has compiled assets. ## The prompts that remain - The **project name**, if you did not pass one; it may contain only letters, numbers, dashes, underscores and periods. - **"Do you want to use a starter kit?"**, defaulting to **no**. Answering no still asks which front-end stack to build on, with Blade preselected; answering yes asks for the kit's stack and authentication provider. The stacks themselves belong to the starter-kit topic. - A kit-specific question or two (single-file Livewire components, teams support) when those apply. Passing a stack flag such as `--react` or `--livewire` skips the starter-kit questions, and `--no-authentication` selects the blank variant of that stack. ## How a starter kit changes the database step When you choose a starter kit, whether at the prompt or with a flag such as `--react`, the installer creates the project from the kit's repository instead of the bare skeleton. Two things follow: - It does not ask about the database at all: with no `--database` flag it sets SQLite. - In that no-flag case it also skips its own migration step, because the kit's own Composer scripts already migrate during `create-project`. With a flag, `laravel new vet-clinic --livewire --database=pgsql` rewrites the PostgreSQL `DB_*` lines and then runs the migrations itself, against PostgreSQL. The kit's pages, authentication features and front-end stack are a separate subject; for this question what matters is that the flags you pass decide the test runner, database, Boost and package manager in exactly the same way. ## Scripting a reproducible install Because the defaults are flags, the team can write one command into its onboarding notes, so every developer's `laravel new` produces the same stack: - `laravel new vet-clinic --phpunit --database=pgsql --no-boost --pnpm` - Pass every flag in scripts: the defaults above are set in the installer's interactive step, so a run with `--no-interaction` and no flags does **not** get Pest or Boost. - Validate the result by checking `composer.json` for the test runner and `.env` for `DB_CONNECTION`. ## Common misreadings - "The installer asks which test framework I want": in v5.32 the choice is pre-set to Pest, and only `--phpunit` changes it. - "Pest is Laravel's default": it is the **installer's** default; the skeleton and `create-project` give PHPUnit. - "Choosing MySQL creates the MySQL database for me": the installer only edits `.env` and runs migrations; the server has to be there.

  • What happens if you run laravel new with --database=mongodb?
    The installer validates the option against its driver list (`mysql`, `mariadb`, `pgsql`, `sqlite`, `sqlsrv`) and throws an `InvalidArgumentException` naming the invalid driver and the allowed values, before anything is created. MongoDB support in Laravel comes from a separate package added after installation, not from the installer.
  • How does the installer turn the skeleton's PHPUnit example tests into Pest tests?
    After swapping `phpunit/phpunit` for `pestphp/pest` and `pestphp/pest-plugin-laravel` and running `pest --init`, it temporarily requires `pestphp/pest-plugin-drift`, runs `pest --drift` to rewrite the example test classes into Pest's function style, and then removes the drift plugin again.

saying these in an interview costs you the question

  • The installer always asks which test framework to use
  • Pest ships in the Laravel skeleton itself
  • --database=pgsql also creates the PostgreSQL database server
  • The installer's default database is MySQL on port 3306
  • Skipping Boost requires deleting the package after install