joshdonnell/laravel-starter-kit-vue
A Laravel starter kit with Vue scaffolding for quickly bootstrapping full-stack applications. It provides a foundation to build on, helping you skip initial setup and focus on developing your app's features. Ideal for developers who want Laravel and Vue wired together out of the box.
This is a starter kit, not a runtime package — there's nothing to composer require and no service provider to register. The v1.4.4 release is mostly documentation/CI housekeeping with one functional fix (vue-sonner styles) and clarified CLI install/update guidance, so the entry path is unchanged:
composer install && npm install && cp .env.example .env && php artisan key:generate && php artisan migrate..starter-kit.json. New in this release series (PR #34), this file records the starter kit version in your project. It's how the CLI knows what to update against — verify it exists after scaffolding.php artisan serve + npm run dev) and hit /login or /register to confirm the auth scaffolding, then trigger a toast to confirm the v1.4.4 vue-sonner fix.Greenfield scaffolding. The primary workflow: bootstrap a new app for a client/internal project, then build domain features on top. Treat everything in resources/js (layouts, components, auth pages) as your local copy going forward.
Updating existing projects via CLI. The PR #39 docs now explain the update flow. The pattern is: CLI reads .starter-kit.json, diffs against a newer starter kit release, and applies changes. Use this for patching core scaffolding (auth, layouts, config) without re-scaffolding. Expect it to be additive/merge-based, not a hard reset.
Version pinning in .starter-kit.json. Commit this file. It documents exactly which starter kit version a project was generated from — invaluable six months later when deciding whether an update is safe.
Toast notifications (vue-sonner). v1.4.4 fixes the missing stylesheet import (PR #37). The pattern is to import the stylesheet once in your root JS entry, then call toast() anywhere in Vue components. Any custom toast styling you added as a workaround should be revisited — it may now conflict or be redundant.
Excluding starter-kit-only files. PR #36 filters CI config and starter-kit-specific tooling out of generated projects. So when you diff your generated project against the upstream repo, expect noise from files that intentionally don't exist in yours — don't try to "sync" them back.
Integration tip: since this is a starter kit, treat the upstream repo as a reference implementation, not a dependency. Copy patterns out of it; don't try to track it as a submodule unless you're actively contributing back.
.starter-kit.json is CLI-owned. Don't hand-edit the version field to "trick" the updater — you'll get incoherent diffs. Regenerate or let the CLI manage it..github/workflows/* exists from the starter, add your own.shivammathur/setup-php, Dependabot grouping, etc. Your app's composer.json/package.json aren't meaningfully affected, but a routine composer update/npm update after pulling is still sensible..starter-kit.json (PR #34, PR #38 scopes write permissions). If you fork and self-host releases, mirror that pattern or the CLI update path breaks.How can I help you explore Laravel packages today?