ministrysites / cornerstone
Opinionated Laravel 13 + Livewire 4 starter kit, wired for strict types, Pest, PHPStan, and Pint out of the box.
Package info
github.com/ministrysites/cornerstone
Type:project
pkg:composer/ministrysites/cornerstone
Requires
- php: ^8.3
- glhd/bits: ^0.6.2
- laravel/framework: ^13.0
- laravel/tinker: ^3.0
- livewire/livewire: ^4.2.0
Requires (Dev)
- fakerphp/faker: ^1.23
- larastan/larastan: ^3.0
- laravel/boost: ^2.0
- laravel/pail: ^1.2.5
- laravel/pint: ^1.27
- ministrysites/cornerstone-devtools: ^0.2
- mockery/mockery: ^1.6
- nunomaduro/collision: ^8.6
- pestphp/pest: ^4.4
- pestphp/pest-plugin-laravel: ^4.1
README
Cornerstone is the Laravel starter kit to spin up new projects. It is a clean Laravel 13 + Livewire 4 base with the tooling, conventions, and quality gates wired in so every new project starts from the same foundation.
This kit is primarily for our own use. If the choices here line up with how you like to build, you are welcome to use it. If they do not, you will almost certainly be happier forking it and reshaping it than trying to bend it to a different philosophy.
Opinions, on purpose
Cornerstone is intentionally opinionated. That is not a temporary state and it is not up for debate on a per-project basis. The whole point of the kit is to encode a specific workflow with specific defaults so that humans and AI tools generating code on top of it land in the same place.
The shape of those opinions:
- Explicit over clever. Strict types on every PHP file. Typed properties, typed return values, narrow public state. No type information in docblocks — if the interpreter can enforce it, the interpreter should.
- Livewire-first. Server-driven components for web UI, Alpine for small client-side niceties. No SPA build pipeline. No duplicated state across a JS framework.
- Tested from commit one. Pest feature tests for user-facing behavior, Pest unit tests for internal business logic, Pest architecture tests for the boundaries we care about.
- Analyzed before merge. Larastan / PHPStan and Pint run locally and in CI.
composer run checkis the gate.
What's in the box
- Laravel 13 on PHP 8.3+
- Livewire 4 for server-driven UI
- Vite 8 + Tailwind CSS 4
- Pest 4 (feature, unit, architecture suites)
- Larastan / PHPStan
- Laravel Pint with a tightened ruleset
- Laravel Boost and Pail for local dev and AI-aware scaffolding
- Customized stubs under
stubs/sophp artisan make:*produces Cornerstone-conforming files out of the box php artisan cornerstone:installfor pulling in predetermined but optional packages
Requirements
- PHP 8.3 or newer
- Composer
- Node.js and npm
- A database supported by Laravel
- A local dev environment that can serve the app over HTTPS (Herd, Valet, or equivalent) is prefered, though you can adjust the HTTPS settings in
AppServiceProviderif you prefer.
Getting started
composer create-project ministrysites/cornerstone my-app
If you already have the repo cloned and just need to set it up:
composer run setup
That script installs PHP and JS dependencies, creates .env from .env.example if needed, generates an app key, runs migrations, and builds frontend assets.
Local development
composer run dev
Runs the Laravel app server, a queue listener, Laravel Pail for logs, and the Vite dev server together.
HTTPS locally
The kit assumes your local environment serves the app over HTTPS. That gives you a secure context for secure cookies, OAuth redirects, and third-party callbacks without surprises. If your environment does not terminate TLS, either add HTTPS support or adjust AppServiceProvider for that environment instead of relying on the starter default.
Quality checks
composer run check is the definition of green. Before opening a pull request or handing work off, it must pass.
composer run check # pint (dirty) + phpstan + pest composer run check:all # pint (full) + phpstan + pest composer run fix # same as check, but pint is allowed to write composer run fix:all # same as check:all, but pint is allowed to write
Individual tools:
composer run pint # format composer run pint:test # check formatting without writing composer run stan # phpstan composer run test # pest in parallel
Architecture conventions
- Livewire is the default for web UI and interactive pages.
- Standard controllers are fine for request-response flows that Livewire does not improve: redirects, OAuth callbacks, webhook endpoints, JSON APIs.
- Validate input explicitly at the boundary where it enters the system.
- Keep Livewire components and controllers thin. When orchestration grows, push it into a typed service in
app/Services/, pass data with readonly value objects inapp/Data/, and put backed enums inapp/Enums/. - Prefer feature tests for user-facing behavior. Use unit tests for isolated logic. Use architecture tests for rules you want to be unbreakable.
The architecture suite enforces several rules without room for negotiation:
- Strict types on every PHP file.
- No type information in docblocks (
@param,@return,@var, array shapes). - No
finalon classes. Extending existing classes is a legitimate pattern here. - No debug helpers (
dd,dump,ray,var_dump) in application code. - No
env()calls outside ofconfig/. - Public Livewire properties must carry
#[Locked],#[Validate],#[Url], or#[Modelable]. - Models use attribute-based configuration (
#[Fillable],#[UseFactory]when using factories).
AI-assisted development
Cornerstone is designed to work well with Laravel Boost and with AI coding tools generally. The guardrails that matter live in three places:
- Pint + PHPStan + Pest. If generated code does not pass
composer run check, it is not done. - Architecture tests. The rules above are enforced by the test suite, not by convention alone.
- Boost guidelines under
.ai/guidelines. The single place to add project-specific AI guidance. Treat it as the primary home for guardrails instead of maintaining separate agent-specific instruction files.
Useful Boost commands:
php artisan boost:install # publish Boost resources (first time) php artisan boost:update # refresh Boost resources after dependency changes
Project layout
app/Livewire— Livewire components for web-facing UIapp/Http/Controllers— controllers for request-response flows that do not fit Livewireapp/Models— Eloquent modelsapp/Services— typed services and actions called from Livewire components and controllersapp/Data— readonly value objects and DTOs (no enums)app/Enums— backed enumsresources/views/layouts/app.blade.php— base Blade layout with Vite and Livewire assetsresources/views/livewire— Livewire component viewsroutes/web.php— web routestests/Feature— Pest feature teststests/Unit— Pest unit teststests/Architecture— Pest architecture tests that encode the kit's rulesstubs/— Cornerstone-customized stubs used byphp artisan make:*.ai/guidelines— project-specific Boost guidance for AI-assisted development.cornerstone/demo-manifest.txt— list of demo files removed byphp artisan cornerstone:cleanup
First customizations
After creating a new project from Cornerstone, the usual first edits are:
- Set the application name and environment values in
.env - Add project-specific routes, Livewire components, and domain models
- Configure queue, mail, cache, and filesystem drivers for the target environment
- Add project-specific Boost guidelines under
.ai/guidelinesfor any conventions unique to the project
Removing the demo content
Cornerstone ships with a small set of demo files: a Livewire homepage, a sample service, a DTO, an enum, and their tests. This allows AI tools have concrete, in-repo examples of the kit's conventions before any real code has been written. Every demo file is tracked in .cornerstone/demo-manifest.txt.
When your project has grown its own examples in each of the directories the demo covered (app/Livewire/, app/Services/, app/Data/, app/Enums/, tests/Unit/, tests/Feature/), run:
php artisan cornerstone:cleanup
The command prints the full list of files it is about to delete, asks for explicit confirmation, and then removes every listed file along with the manifest itself. Running it earlier leaves AI tooling and new contributors without a reference shape to follow. Git history is your safety net if you change your mind.
GitHub setup
If you host the project on GitHub, protect main before team use:
- Require pull requests before merging
- Require passing CI checks before merging
- Block direct pushes to
main
Contributing
Issues and pull requests are welcome, but the scope of this kit is narrow on purpose. The fastest way to get a contribution accepted is to keep it focused on:
- fixing bugs
- improving reliability
- clarifying behavior or documentation
- improving maintainability without changing the kit's opinions
Pull requests that add features, broaden the scope, or change the underlying opinions and defaults are unlikely to be merged. If you need materially different behavior, fork the kit and adapt it to your own conventions.
License
Cornerstone is open-sourced software licensed under the MIT license.