Starter Kit Laravel Package

Getting Started

rockero-cz/starter-kit is a project scaffold, not a runtime dependency. You do not composer require it into an existing app — you copy or create a project from it, then own the code outright. Treat day one as "fork and forget upstream exists" unless you deliberately want to track it.

Minimal kickoff:

# If it is published on Packagist as a create-project target:
composer create-project rockero-cz/starter-kit my-app

# Otherwise (most likely), clone and detach:
git clone https://github.com/rockero-cz/starter-kit.git my-app
cd my-app && rm -rf .git && git init
composer install
cp .env.example .env
php artisan key:generate

Then, in order:

1. README — with 32 stars this is your only documentation. Read it end-to-end before running anything; it usually lists required PHP/Node versions and the intended auth/admin stack.
2. composer.json — the require/require-dev block and the scripts section tell you what the author actually wired up (Pest/PHPUnit, Pint, PHPStan/Larastan, Rector, Sail, etc.). The scripts are the fastest way to discover the intended dev loop (composer test, composer lint).
3. composer.lock / package.json — pin down which Laravel major this targets. A starter kit from Oct 2024 is likely Laravel 11; check before assuming 12-era conventions.
4. Diff against a clean install — the single most useful orientation step:

composer create-project laravel/laravel /tmp/vanilla
diff -rq /tmp/vanilla . --exclude=vendor --exclude=node_modules

That diff is your map of everything the author added or changed: service providers, config tweaks, migrations, seeders, routes, frontend setup, Docker, CI.

First real use case: stand up a new internal app with auth and whatever admin/dashboard layer ships prewired, migrate and seed, log in with the seeded user, then strip the demo content. If that loop takes under ten minutes, the kit is doing its job.

Implementation Patterns

Use it as a create-project template, not a fork you pull from. After kickoff, the repo is yours. Delete the upstream remote. Keeping a remote you never merge from is a common source of accidental git pull disasters.

The "reference diff" pattern. If you don't want to commit to the kit's opinions, don't. Instead keep it as an ideas source: clone it beside your project, and when you need a pattern (CI workflow, Docker compose, Pest setup, static analysis config), copy the specific file rather than adopting the whole scaffold. This is the safest way to use a low-maintenance starter kit.

Cherry-pick upgrades, don't merge them. If you do want upstream improvements:

git remote add starter https://github.com/rockero-cz/starter-kit.git
git fetch starter
git log --oneline starter/main   # review; don't merge
git checkout -p starter/main -- path/to/file   # take individual hunks

Because the kit is a snapshot, a plain git merge will conflict on nearly every file once you've customized anything.

Integration tips by area:

• CI — the .github/workflows/*.yml files are often the most valuable part of a starter kit. Copy them into projects that didn't start from this kit; they encode a working matrix of PHP version × Laravel version × database.
• Static analysis — run the shipped PHPStan/Larastan config on day one before writing code. It establishes a baseline; if you wait, you'll be drowning in pre-existing errors later and will be tempted to lower the level.
• Testing — run the preconfigured suite immediately after setup. If it's green on a fresh clone, the scaffold is internally consistent. If it isn't, that's your signal about maintenance quality and you should budget time accordingly.
• Docker/Sail — if docker-compose.yml is present, prefer it over a local PHP install for the first boot. Version mismatches between the kit's assumptions and your machine are the #1 first-run failure.
• Localization — Czech-authored kits sometimes ship with cs locale defaults, translated validation strings, or a lang/ directory. Check config/app.php locale and the contents of lang/ before you start writing user-facing strings.

Team adoption pattern. If you're introducing this to a team, fork it into your own org, pin a specific commit, and make that fork the official template. Never point teammates at an unmaintained third-party repo you don't control.

Gotchas and Tips

• No upgrade path. This is the defining limitation. There is no composer update that migrates your app to Laravel 12. When a new Laravel major lands, you either upgrade manually or re-scaffold and port your code. Budget for that.
• The lock file is the truth. The README may claim Laravel 11 while composer.lock says something else, or vice versa. Trust the lock.
• composer create-project may not work. Many small starter kits are not published to Packagist, or are published but stale relative to the repo. If it fails, clone instead — don't burn time debugging Composer repository resolution.
• Seeded credentials are in the seeder, not the README. Look in database/seeders/ for the default user. Don't ship a starter kit's demo login to production; delete or change it before the first deploy.
• .env.example drift. Starter kits frequently add config keys to .env.example without a corresponding config/*.php entry, or reference env vars in config that aren't documented. Grep for env( across config/ after setup to find silent nulls.
• Default admin/demo routes. Remove or gate any /admin, /dashboard, or debug routes before going live. Starter kits exist to demo, not to be secure by default.
• Stale JavaScript dependencies are the quiet killer. npm install on a 2024 snapshot will pull an old Vite/Tailwind combination that may not build on current Node (18 is EOL; 22+ can break older Vite). If the build fails, check package.json engines and Node version before debugging anything else.
• License and attribution. MIT means you can use it freely, but the license file should be preserved unless you're explicitly relicensing your own project. Check whether the kit ships a LICENSE you're expected to keep.
• Low-signal maintenance. With 32 stars and a 2024-10 release, assume no future updates. Run composer outdated and npm audit during setup and decide then whether to upgrade the dependency tree before you write a line of feature code — it's far cheaper at t=0 than at t=6 months.
• Extension points are just Laravel. There's no plugin system to learn. Customize via config files, service providers, and — if the kit ships them — published stubs (stubs/ directory used by make:* commands). If you want to reshape generated code, check php artisan stub:publish output versus anything the kit already overrode.
• Audit the CI before trusting it. Starter-kit workflows sometimes run against ubuntu-latest with unpinned action versions or skip the test suite on certain branches. Read the YAML; it's short, and it's the difference between real coverage and theater.