Laravel Starter Kit React Laravel Package

Getting Started

This is a Laravel application starter kit (Laravel + React/Inertia), not a runtime library you composer require into an existing app — so "getting started" means scaffolding on top of it rather than installing it as a dependency.

1. Clone or use as template: git clone https://github.com/shire-studio/laravel-starter-kit-react my-app && cd my-app (or "Use this template" on GitHub).
2. Install PHP + JS deps: composer install && npm install (or pnpm install — check the lockfile committed at the tag).
3. Environment: copy .env.example → .env, php artisan key:generate, configure DB_*, then php artisan migrate (optionally --seed).
4. Run it: npm run dev alongside php artisan serve (or composer run dev if the kit ships a compound script).

Where to look first, in order:

• composer.json / package.json — pin the stack versions (Framework, Inertia, React, Vite, and whatever UI/auth layer the kit ships).
• config/ — this release specifically removed bloom config from starter kits, so if you were following an older blog post referencing a bloom.php config, it's gone. Don't chase it.
• routes/web.php + app/Http/Middleware/HandleInertiaRequests.php — the Inertia wiring is the backbone of every page you'll add.
• resources/js/Pages and resources/js/Layouts — your day-to-day surface area.

First use case: scaffold the app, get the default authenticated dashboard rendering end-to-end (Inertia page → React component → props from controller) before touching any domain code. That single loop is 90% of the development experience in this kit.

Implementation Patterns

Controller → Inertia → React props. The idiomatic flow: return Inertia::render('Page/Name', ['prop' => $value]) and type the props on the React side. Keep prop payloads narrow — Inertia serialises everything to JSON, so pass DTOs/arrays, not Eloquent models with lazy relations that will explode on serialisation.

Form submissions. Use useForm from @inertiajs/react for POST/PUT/PATCH/DELETE, and let Laravel's validation errors flow back automatically via the shared errors prop. Combine with Form Requests server-side; don't hand-roll fetch calls for mutations.

Shared data. Anything needed on every page (auth user, flash messages, app name, feature flags) belongs in HandleInertiaRequests::share(), not repeated in each controller.

Partial reloads for performance. When a page has expensive props, guard them behind Inertia::lazy() or Inertia::optional() and use router.reload({ only: [...] }) — this is the primary performance lever in Inertia apps and the one most commonly missed.

Auth scaffolding as a baseline, not gospel. Starter kit auth (controllers, routes, React pages) is designed to be edited in place. Fork the existing controllers rather than layering a package on top — mixing a third-party auth package with the kit's Inertia pages causes prop-shape mismatches.

CI/dependency hygiene. This release holds back dependency releases for two days (chore: vet hobbiton's dependencies) before they're picked up. Mirror that in your fork: let Renovate/Dependabot open PRs, but gate auto-merge behind a short delay and a passing test job. Starter kits rot fast otherwise.

Gotchas and Tips

No bloom.php config as of v1.0.1. If tooling, docs, or your own earlier scaffolding expects bloom config keys, they're now absent — the relevant behaviour falls back to package defaults. If you need customisation, publish the config explicitly rather than assuming the file ships.

Starter kits are snapshots, not dependencies. There is no composer update path that brings in kit improvements. Upstream fixes (like the one in this release) only reach you via manual diffing against the repo or a rebase of your fork. If you diverge heavily, track upstream commits in a separate branch and cherry-pick — don't expect mergeable history.

Two-day release delay is a feature, not a bug. Don't "fix" it by pinning bleeding-edge versions in your own fork. Version pinning in composer.lock / package-lock.json should stay committed.

Vite dev server + Inertia SSR. If you enable SSR (php artisan inertia:start-ssr), npm run dev alone isn't enough — you need the SSR build running too, otherwise pages silently fall back to client rendering and you'll chase phantom hydration warnings. Most people never need SSR on this kit; skip it until you have a measured reason.

Serialisation traps. Dates, Carbon instances, and enum values inside props come out differently than you'd expect on the JS side. Cast explicitly in your DTOs or use Eloquent $casts and API Resources rather than raw model dumps.

Validation error shapes. Inertia's errors prop is a flat map keyed by field name — nested fields use dot notation (address.city). React forms need to read the dotted key, not a nested object.

Debugging Inertia props. dd() in a controller kills the whole Inertia response and dumps JSON in the network tab — useful, but confusing if you're expecting an HTML dump. Prefer Inertia::share + React devtools, or Laravel Telescope for a cleaner trace.

Extension point worth knowing: resources/js/app.tsx is where you register global components, plugins, and progress-bar config. Any third-party React library integration (charts, rich text) should be wired there or in a Layout, not sprinkled per-page.

Upgrading the kit's stack (Laravel major, Inertia v2, React 19) is manual work. Read the kit's changelog first — minor releases like this one (dependency vetting, config cleanup) are safe, but major bumps in starter kits routinely require changes across bootstrap/app.php, middleware registration, and the Vite config simultaneously.