Laravel Starter Kit Api Laravel Package

Getting Started

This is a Laravel starter kit (shire-studio/laravel-starter-kit-api) — an API-oriented application scaffold, not a runtime library you composer require into an existing app. Get going with:

1. Create a new project from the kit (typically laravel new my-api --using=shire-studio/laravel-starter-kit-api or by cloning the repo and running composer install).
2. Copy .env.example to .env, set your DB connection, and run php artisan key:generate.
3. Run php artisan migrate (and seed if seeders are provided) to get a working baseline.
4. Look first at routes/api.php, the app/Http/Controllers directory, and any config/ files the kit ships — that's where the opinionated API wiring lives.

First use case: stand up an authenticated JSON API quickly — scaffold the project, confirm the health/auth routes respond, then start adding your own resources on top of the provided structure. In v1.0.1 the starter kits no longer ship a Bloom config, so don't go looking for one; authentication/authorization scaffolding is whatever the kit's own config provides.

Implementation Patterns

• Scaffold-and-own: treat the kit as a starting point you fork mentally. Once generated, the code is yours — don't expect upstream fixes to flow in automatically. Record the kit version you scaffolded from so you can diff against future releases.
• Layer your domain on top of the kit's conventions rather than fighting them: follow the existing controller/request/resource patterns, route grouping, and middleware setup so upgrades remain comparable.
• Pin your dependencies deliberately. The v1.0.1 changelog notes that dependencies are vetted and releases are held back ~2 days. Mirror that discipline in your own composer.lock — avoid composer update in production windows, and review lockfile diffs before deploying.
• CI integration: since this is an API kit, wire up feature tests against the JSON endpoints early. Use RefreshDatabase and assert on response shapes rather than internal implementation, so future kit-inspired refactors don't break your suite.
• Config over code: anything the kit exposes in config/ should be overridden via env vars in deployment rather than edited in place. The v1.0.1 "remove bloom config" change is a reminder that starter-kit config files can be dropped between versions.

Gotchas and Tips

• Starter kits are not upgradeable packages. There is no composer update path to pick up v1.0.1 changes in an existing project. If the Bloom-config removal matters to you, diff the release against your scaffold manually.
• The v1.0.1 changes are housekeeping, not features. "Remove bloom config from starter kits" and "vet dependencies / hold releases for 2 days" are maintenance items — no breaking API changes, new endpoints, or deprecations are announced. Upgrading is low-risk but also low-value unless you're re-scaffolding.
• Missing Bloom config is intentional. If you previously relied on a Bloom config file being present in a freshly generated project, add it back yourself (or install Bloom explicitly) — don't assume it ships.
• First-contributor release: v1.0.1 is the first tagged release with external contribution activity, so treat it as early-stage. Pin the exact version you scaffold from and watch the changelog for the next few releases before betting production architecture on it.
• Debugging tip: if generated API routes 404 or auth fails, verify route registration in bootstrap/app.php (Laravel 11+ style) and that you ran the kit's documented post-install commands — starter kits often rely on a composer setup or similar script.
• Extension point: the kit's own service providers and config/ files are your sanctioned extension surface. Prefer binding your own implementations there over editing vendor-adjacent scaffold files, which makes it easier to compare against upstream.