2.3 KiB
Repository Guidelines
Project Structure & Module Organization
The application follows Laravel 12's streamlined tree. Server code lives in app/, with Livewire & Volt components under app/Livewire and HTTP actions under app/Http. Volt views and shared blades live in resources/views, UI assets in resources/js and resources/css. Routes are split across routes/web.php, routes/api.php, and CLI automation in routes/console.php. Database migrations, factories, and seeders live within database/. Automated tests are grouped by layer in tests/Feature and tests/Unit.
Build, Test, and Development Commands
Use composer run dev for the full local stack (PHP server, queue listener, Pail, and Vite). Frontend-only work can rely on npm run dev, while npm run build compiles production assets. composer test clears config cache then runs the Pest suite. Run targeted tests via php artisan test tests/Feature/FooTest.php. When onboarding, execute composer run setup to install dependencies, provision .env, migrate, and build assets.
Coding Style & Naming Conventions
PHP code targets 8.4+ and follows Laravel Pint defaults; run vendor/bin/pint --dirty before committing. Use descriptive camelCase for variables and methods, and PascalCase for classes, Livewire components, and enums. Volt components should keep their Blade/PHP in a single .blade.php file and align with existing Flux UI usage. Tailwind v4 powers styling—reference the utility-first classes already present in resources/css/app.css.
Testing Guidelines
Write tests with Pest v4, mirroring the structure under tests/Feature for HTTP and Livewire flows and tests/Unit for pure logic. Prefer model factories and Volt testing helpers (Volt::test) to cover component behavior. Name tests after user-facing behavior and exercise validation errors alongside success paths. Always run the nearest relevant php artisan test command before pushing.
Commit & Pull Request Guidelines
Commits are short, present-tense summaries (for example, add billing address migration). Bundle related changes together and include schema updates with their factories and tests. Pull requests should describe the change, list validation steps (commands run, screenshots for UI), and link to any tracked issue. Flag follow-up work clearly so reviewers can plan next steps.