17 lines
2.3 KiB
Markdown
17 lines
2.3 KiB
Markdown
# 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.
|