cranux/laravel-dev-template
cranux/laravel-dev-template is a Laravel starter template that gives new projects a ready-made development foundation, with sensible defaults and project structure to help you scaffold faster, reduce boilerplate, and start building features sooner.
cranux/laravel-dev-template is a project skeleton, not a Composer library — there is nothing to composer require. Treat it as a forkable starting point (or a source of copy-paste patterns) rather than a dependency.
Minimal path to a running app:
git clone https://github.com/cranux/LaravelDevTemplate my-app
cd my-app && rm -rf .git # start your own history
composer install
cp .env.example .env && php artisan key:generate
# pick ONE of the following based on what the repo actually ships:
php artisan migrate --seed # bare-metal / local PHP
# or: docker compose up -d && docker compose exec app php artisan migrate --seed
# or: ./vendor/bin/sail up -d && ./vendor/bin/sail artisan migrate --seed
Where to look first, in this order:
README.md — the description is Chinese ("laravel 高效开发模板", i.e. "efficient Laravel dev template"), so the setup notes, PHP/Node versions, and any opinionated conventions are likely documented there. Read it end-to-end before running anything.composer.json — this is your single most important file. It tells you the actual Laravel version (laravel/framework), PHP constraint, and every pre-installed package (debugbar, ide-helper, admin scaffolding, auth starter, etc.). Compare that list against what you'd install yourself..env.example — reveals assumed services: queue driver (redis?), cache, mail, DB, S3. Any service listed here must exist before boot succeeds.docker-compose.yml, Dockerfile, sail, .devcontainer/, Makefile. These usually explain why this template exists.app/ and routes/ — skim for base controllers, response wrappers, service/repository layers, and custom middleware that you'd otherwise build from scratch.First real use case: spin it up locally, run the test suite (php artisan test or ./vendor/bin/phpunit), and confirm green before changing a line. A template that doesn't pass its own tests on your machine is a red flag worth catching on day one.
Pattern 1 — Greenfield fork (the intended use). Clone, strip .git, rename the app namespace if the template hardcodes one, then commit an "initial import" commit unmodified. That gives you a clean baseline diff for every subsequent change and makes it trivial to compare against upstream later.
Pattern 2 — Keep upstream as a remote for cherry-picking. If the template is actively maintained, this is the highest-leverage workflow:
git remote add template https://github.com/cranux/LaravelDevTemplate
git fetch template
git log --one-line template/main ^main # see what you're missing
git cherry-pick <sha> # pull only the fixes you want
Because there's no package boundary, you get zero automatic security updates — this manual diff review is your only upgrade channel.
Pattern 3 — Harvest, don't adopt. For an existing production app, don't migrate into the template. Instead diff the two and lift specific pieces:
Controller / ApiResponse trait / exception handler → copy, then reconcile with your existing handler.config/ tweaks and .env conventions → cherry-pick individually.This is usually the right call: 22 stars and 0 dependents means the template carries no community upgrade guarantee, so the less of it you own, the better.
Pattern 4 — Day-to-day workflow once adopted. Standard Laravel muscle memory applies, but anchor your team to the template's conventions deliberately:
php artisan make:* still works; check stubs/ in the repo — templates often publish custom stubs, and your generated files should match them.Makefile/Composer scripts (composer test, composer lint) so onboarding stays one command.Integration tips. Pin the Laravel and PHP versions in composer.json and your Dockerfile to the same values the template's CI uses — drift here is the most common breakage. If you keep the template's Docker image, tag it rather than using latest.
composer update will ever bring you template fixes. Budget for periodic manual diffs, or accept it as a one-time scaffold. Do not add it to require-dev.composer.json first: if laravel/framework is more than a major behind, the container config, stubs, and conventions will fight your upgrade — you'll spend more time fixing the template than it saves. Prefer a fresh laravel new + selectively copied ideas in that case.rm -rf .git before you commit. Cloning leaves upstream history and remotes; committing your app on top of someone else's history is messy and can leak their commit metadata..env.example may contain real-looking credentials or service assumptions. Never copy it to .env on a shared machine without auditing; and never commit a .env derived from it..env defaults to database, you'll get confusing queue behavior rather than a hard error. Run php artisan about after boot to see the effective drivers.storage/ and bootstrap/cache/ correctly for your OS; php artisan storage:link and chmod -R ug+rwX storage bootstrap/cache fix 90% of "500 on first load".grep -ri "cranux\|LaravelDevTemplate" --include="*.php" --include="*.json" --include="*.env*" .require rather than require-dev. Move them and re-run composer update --lock — otherwise your production image bloats and IDE helpers regenerate on deploy.composer install errors → PHP extension mismatch (check Dockerfile's docker-php-ext-install line against your composer.json platform reqs); artisan errors → missing .env/APP_KEY; DB errors → service not up or wrong host (db vs 127.0.0.1 inside containers is the classic).config/ files, and the Dockerfile are your hooks. Because you own the code, "extending" means editing — which is freeing on day one and a maintenance cost by month six. Keep a TEMPLATE_CHANGES.md noting every place you diverged from upstream; future-you will need it.How can I help you explore Laravel packages today?