skip to content

What does it mean in practice that a Laravel starter kit's code is yours, and how do you keep a starter-kit app up to date?

level: middleimportance: must knowfreq 42%

answer

  1. composer create-project, not composer require
  2. no kit package in vendor
  3. Fortify, Inertia, Livewire, Flux still update
  4. shadcn components copied into resources/js
  5. delete features, then fix the front end

basics

~20 s

A starter kit copies a whole application into your repository; there is no kit package to update. You edit its screens, actions and routes freely and keep the underlying packages (framework, Fortify, Inertia or Livewire, Flux) current with Composer and npm.

solid answer

~40 s

The installer runs `composer create-project` on the kit, so its controllers, pages, layouts, `app/Actions/Fortify` classes, routes and tests land in your repository as ordinary source. Nothing named "starter kit" sits in `vendor`, and the docs say there is no need to update the kit itself — later kit releases never reach your app. What you do still update are the **dependencies** the kit declared: `laravel/framework`, `laravel/fortify`, and either `inertiajs/inertia-laravel` with the JavaScript adapter or `livewire/livewire` with `livewire/flux`, via `composer update` and npm. The shadcn components are copied files, so upgrading one means re-running the generator or merging by hand. Removing a feature is your job too: disable it in `config/fortify.php` and delete its screens and route references, or an Inertia kit's Wayfinder build fails.

code

bash · 6 lines
bash
# the kit's own code is never updated; its dependencies are
composer update laravel/framework laravel/fortify inertiajs/inertia-laravel
npm update @inertiajs/react

# regenerate a copied shadcn component, then review the diff
npx shadcn@latest add dialog

go deeper

for a junior

Remember that a kit copies a whole app into your repo, so you edit its files freely and nothing called a starter kit sits in vendor.

for a middle

Separate what you own from what you depend on, and explain why removing a Fortify feature also means deleting pages in Wayfinder-based kits.

for a senior

Plan maintenance: dependency upgrades with changelog review, porting worthwhile kit changes by hand, and tests covering the auth flows you changed.

for a principal

Weigh generated source against runtime packages for scaffolding: full control and no forced upgrades versus owning every future fix.

## Two models of scaffolding There are two ways a framework can hand you authentication screens: 1. **A runtime package** that registers routes and views from `vendor`, which you configure and occasionally override. Upgrades arrive with `composer update`; customisation is limited to what the package exposes. 2. **Generated source** copied into your application once. Everything is editable; nothing upgrades automatically. Laravel's current starter kits are firmly the second model. The installer runs `composer create-project laravel/react-starter-kit my-app` (or the Vue, Svelte or Livewire kit), and the kit's `composer.json` has `"type": "project"` — it is an application template, not a library. ## What lands in your repository For the React kit, for example: | Area | Files you now own | |---|---| | Auth business logic | `app/Actions/Fortify/CreateNewUser.php`, `ResetUserPassword.php`, validation-rule concerns | | HTTP layer | `app/Http/Controllers/Settings/*`, `HandleInertiaRequests`, form requests | | Front end | `resources/js/pages`, `layouts`, `components`, `hooks` | | UI primitives | `resources/js/components/ui/*` — shadcn components as source | | Routes and tests | `routes/web.php`, `routes/settings.php`, PHPUnit feature tests | | Providers | `FortifyServiceProvider`, which tells Fortify which views to render | The Livewire kit has the same shape in Blade: pages under `resources/views/pages`, layouts, partials and a `resources/views/flux` folder for customised Flux components. ## What you do not own "Your code" does not mean "no dependencies". The kit's `composer.json` and `package.json` declare packages that keep evolving: - `laravel/framework` and `laravel/fortify` for everything; - `inertiajs/inertia-laravel`, `laravel/wayfinder` and the Inertia client adapter in the React, Vue and Svelte kits; - `livewire/livewire` and `livewire/flux` in the Livewire kit; - Tailwind, Vite and the component primitives (Radix for React, Reka UI for Vue) on npm. Those update the normal way, and their changelogs matter: a Fortify or Inertia major can require edits in files the kit generated. ## How upgrades actually work - **The kit itself**: never. The docs' FAQ says there is no need to update the starter kit; you started from it and moved on. - **Dependencies**: `composer update` and `npm update` within your constraints, with major upgrades done deliberately. - **Improvements in newer kit releases**: if you want one, you port it by hand — compare the kit repository's history and merge what you need, like any other upstream reference. - **shadcn components**: re-run `npx shadcn@latest add <component>` to regenerate a component (reviewing the diff against your edits) or leave it as it is. ## Trimming what you do not need Because everything is local, removing a feature is a code change: 1. At creation time, the kit's post-create hook `php artisan install:features` asks which auth features to keep (email verification, registration, two-factor, passkeys, password confirmation) and removes the rest for you. 2. Later, you remove the feature from `config/fortify.php`'s `features` array **and** delete the pages and links that used it. In the Inertia kits the second step is mandatory: Wayfinder generates route definitions at build time, so a page importing a route that no longer exists breaks `npm run build`. ## A worked example Suppose the product owner wants registration to collect a job title. In a kit app the whole change is local: 1. Add a migration for the column and list it in the `#[Fillable([...])]` attribute on the kit's `User` model. 2. Add the field and its validation rule in `app/Actions/Fortify/CreateNewUser.php`. 3. Add the input to the registration page (`resources/js/pages/auth/register.tsx` in the React kit). 4. Extend the existing registration feature test. No package view has to be published or overridden, and no package upgrade can later undo the change. The same edit in a Jetstream app meant finding which of those pieces the package owned. ## Why Laravel chose this model Generated source removes the "how do I override the package's view" problem that runtime scaffolding creates, and makes the kit readable as ordinary application code. The price is that security and UX fixes in later kit versions are not delivered automatically — you own them the way you own any other code. ## A good interview answer State both halves: *the scaffolding is mine to change and will never be upgraded for me*, and *the packages underneath are still dependencies I keep current*. Then give one consequence of each, such as editing `CreateNewUser` freely versus handling a Fortify major upgrade.

  • You remove Features::emailVerification() from config/fortify.php in a Vue-kit app and npm run build now fails. Why?
    The Vue kit uses Wayfinder, which generates route definitions from Laravel's routes at build time. Fortify no longer registers the verification routes, but the kit's pages still import them, so the build cannot resolve those imports. Delete the verification page and its links, or keep the feature.
  • How did Jetstream differ on this point?
    Jetstream stayed a runtime dependency: its service provider loaded routes from the package, and your `User` model used its `HasTeams` and `HasProfilePhoto` traits, so upgrades came through `composer update` and customisation meant working around the package. The current kits hand you all of that as your own code instead.

It is like buying a house built from a published floor plan rather than renting a furnished flat. You can knock down walls whenever you like, but the architect's later revisions never appear in your house; the mains water and power, though, still come from the utility and still get upgraded.

saying these in an interview costs you the question

  • composer update pulls in the latest starter kit changes automatically
  • Owning the code means the app has no framework or Fortify dependency to maintain
  • The shadcn components are installed from npm and update with npm update
  • Removing a Fortify feature in config is enough; the front end adjusts itself
  • You must never edit the generated Fortify action classes