Laravel Starter Kit Vue Laravel Package

Getting Started

This is a starter kit, not a runtime package — you consume it once to scaffold an app, not composer require it into an existing one. Treat v1.4.6 as the scaffold baseline.

1. Read the README first. PR #32 in this release was specifically a docs correction, and PR #39 added the "installing and updating projects with the CLI" section — that section is the authoritative source for command names and flags. Do not guess the CLI verb; copy it from the README.
2. Scaffold a throwaway project before using it for real work. The kit ships opinionated frontend wiring (Vue + toast notifications via vue-sonner), and PR #36 changed which files are excluded from generated projects — you want to see what actually lands on disk, not what exists in the GitHub repo.
3. Check .starter-kit.json in the generated project. New in this release line: the release workflow writes the kit version into this file. It's your provenance record — confirm it matches v1.4.6 immediately after scaffolding. If it's missing or stale, your CLI is pulling an older tag.
4. First real use case: scaffold, composer install && npm install, boot the app, trigger a toast. The toast is the fastest smoke test that the frontend build, the vue-sonner stylesheet import (fixed in PR #37), and the Inertia/Vue entrypoint are all wired correctly.

Implementation Patterns

Scaffold-then-own. Once generated, the project is yours — there is no upstream merge path for your application code. The practical pattern is: keep app-specific work in namespaced directories and leave kit-provided files (config, base components, layout shell) as close to upstream as possible, so a later kit update is a diff you can read rather than a rewrite.

Version pinning via .starter-kit.json. Because the version is recorded at release time, you can wire it into CI to assert the scaffold is current:

# fail the build if the project was scaffolded from an old kit
test "$(jq -r .version .starter-kit.json)" = "$EXPECTED_KIT_VERSION"

Useful on teams where several people scaffold at different times.

Updating an existing project. The CLI supports updating, but an update against a heavily modified app is a merge, not a patch. The workflow that holds up: update on a clean branch, run the update, inspect the diff file-by-file, and treat any change to files you've customised as a manual port. Never let the updater overwrite application logic blindly.

Starter-kit-only files are excluded. As of PR #36, files that exist to maintain the kit itself (CI workflows, release scripts, dependency tooling) are stripped from generated projects. Pattern: don't add app features to files you know are kit-maintenance files — they won't be there in the generated output, and you'll chase a bug that only reproduces in the source repo.

Dependency intake lag. PR #43 introduced holding back releases for two days while dependencies are vetted. Build this into your expectations: the kit will lag upstream by design. If you need a security patch immediately, override the pin in your own composer.json/package.json rather than waiting for a kit release.

Gotchas and Tips

• The repo is not the output. The biggest trap with any starter kit, sharpened here by the file-exclusion change in PR #36: browsing the GitHub tree tells you what the maintainers work with, not what you get. Always inspect a freshly generated project.
• vue-sonner styles were broken before this release. If you scaffolded on an earlier tag and your toasts render unstyled or invisible, that's PR #37's fix — the stylesheet import was missing. Confirm the import exists in your entrypoint before debugging anything else.
• Bloom config was removed. PR #42 deleted the Bloom config from the starter kits. If you're following older tutorials or a blog post that references it, that file is gone — don't add it back expecting it to work.
• Version drift between repo and generated app. The .starter-kit.json write happens in the release workflow, so a tag can exist without a corresponding recorded version if that job fails. Verify after scaffolding rather than assuming.
• The 2-day dependency hold is deliberate, not neglect. Don't open issues about lagging dependency versions until the window has passed.
• Config quirks live in the kit's published config, which you should treat as read-mostly. When you must change it, note the change in your own README or an UPGRADING.md — otherwise the next kit update diff is ambiguous about whether a line is upstream or yours.
• Extension point: the frontend entrypoint and the layout shell are the two files you'll touch most; both are designed to be replaced wholesale if you outgrow the kit's opinions. Anything under the kit-maintenance exclusions is not an extension point at all.
• Debugging order for a broken scaffold: .starter-kit.json version → CLI version you invoked → composer install/npm install output → asset build. Frontend failures in this kit are almost always install or build, rarely Vue code.

Assessment of v1.4.6: documentation, CI, and dependency housekeeping, plus three behavioural fixes (stylesheet import, file exclusions, Bloom removal) and a new version-recording mechanism. No breaking changes for anyone already generated from the v1.4.x line, but if you're on v1.4.1 or earlier, re-scaffolding or running the CLI update is worth it purely for the vue-sonner fix.