Laravel Nuxt Shadcn Laravel Package

Getting Started

This is a scaffolding/starter-kit package, not a runtime library — you consume it once to generate an application, then you own the output. Day-to-day leverage comes from how quickly you can spin up a Laravel + Nuxt + shadcn-vue app with auth, a dashboard shell, and a component library already wired together.

Look at these first, in order:

1. README — the installer command is the whole contract. Expect either composer create-project derrickobedgiu1/laravel-nuxt-shadcn my-app or Laravel's starter-kit flow (laravel new my-app --using=derrickobedgiu1/laravel-nuxt-shadcn). Use whichever the README documents for the tag you pinned.
2. The package's composer.json and src/ — find the install command class and the stubs/ directory. The stubs are the product; everything you get is a file copied from there.
3. The generated app's composer.json name, README.md, and package.json — this is exactly what v0.2.2 fixed.

Minimal first run:

composer create-project derrickobedgiu1/laravel-nuxt-shadcn my-app   # or laravel new --using=...
cd my-app
cp .env.example .env && php artisan key:generate
php artisan migrate
npm install
npm run dev        # Nuxt
php artisan serve  # Laravel, second terminal

First use case to validate the whole stack: register a user through the generated auth pages, confirm the session/Sanctum handshake works, then land on the dashboard and render one shadcn-vue component (e.g. a Card with data fetched from a Laravel route). If that loop works, the scaffold is sound.

Implementation Patterns

Scaffold-per-project, then detach. Do not add this package as a require in an app you intend to maintain. Generate, commit the generated tree as your initial commit, and treat the starter kit as upstream reference only. This makes upgrades a diff exercise, not a dependency upgrade.

Own the identity immediately. v0.2.2 resets the package name and ships the app README into generated apps, so composer.json name, APP_NAME, and README.md should now be correct out of the box. Still verify and then customize: app name, .env, branding, package.json name, and the Nuxt app.config/nuxt.config title. Add a short "generated from laravel-nuxt-shadcn vX.Y.Z" note in the README so future-you knows the provenance.

Frontend integration pattern. shadcn-vue components land in the Nuxt app (typically components/ui/). Add more with the standard CLI inside the generated app:

npx shadcn-vue@latest add dialog

Then compose them in pages/ and keep data fetching in composables/ or useAsyncData/$fetch calls so pages stay presentational.

API/auth boundary. Keep Laravel as the JSON/session authority and Nuxt as the consumer. Use Sanctum's SPA (cookie) flow for first-party auth rather than token juggling, and centralize $fetch config in a Nuxt plugin so credentials: 'include' and the base URL are set once.

Team workflow. Pin the starter-kit version in your onboarding docs. When you want the v0.2.2 fixes in an existing app, either re-scaffold into a temp directory and diff, or manually patch composer.json name and README.md — those are the two changes in this release.

CI smoke test. Because the package's job is to produce a working app, the highest-value test you can write is: scaffold from the pinned version, composer install, npm ci, php artisan migrate --force against SQLite, npm run build. That catches stub breakage before it reaches a teammate.

Gotchas and Tips

• v0.2.2 is a correctness fix, not a feature. If you generated an app on v0.2.1 or earlier, your composer.json name and README.md are almost certainly wrong (carrying the starter kit's identity). Fix them by hand or regenerate and diff — don't just bump a version number, because there's nothing to bump.
• Pin the version. Scaffold output changes between releases and there is no migration path. v0.2.2 today may produce a materially different tree than v0.3.0 tomorrow. Reference the tag explicitly in docs and CI.
• Two dev servers, two failure modes. Nuxt and Laravel run separately. A blank page is usually the Nuxt side; a 419/401 is almost always the Laravel side. Check both terminals before debugging code.
• Sanctum configuration is the usual culprit. For SPA auth, SANCTUM_STATEFUL_DOMAINS must include your Nuxt dev host and port, SESSION_DOMAIN must match, and requests need credentials: 'include'. Misconfiguration here looks like "auth is broken" but is really a cookie-domain problem.
• shadcn-vue components are copied, not installed. Once generated they're your source files — edit freely, but they will not receive upstream fixes. Don't expect npm update to touch them.
• Node and PHP version floors. Check the generated composer.json require.php and package.json engines before assuming your local toolchain is fine. Mismatches often surface as confusing install errors rather than clear version messages.
• Extension point is the stub tree. If you need org-wide conventions (extra Pint rules, a base layout, a standard .env), the clean move is to fork the package and edit stubs/ rather than post-processing every generated app with a script.
• Debugging generated-app issues. Reproduce in a fresh scaffold from the pinned tag. If it reproduces there, it's a starter-kit issue worth an upstream PR; if not, it's local drift in your app. This one question resolves most confusion.