Skip to content

Commit ee4ebc4

Browse files
UbeyduUbeydu
authored
Merge pull request #275 from Ubeydu/install-laravel-boost
Install Laravel Boost MCP server and add development guidelines
2 parents 37286c8 + 2900b25 commit ee4ebc4

File tree

5 files changed

+824
-2
lines changed

5 files changed

+824
-2
lines changed

‎.junie/guidelines.md‎

Lines changed: 309 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -40,4 +40,313 @@ It is not Kernel.php. Kernel.php exists in older Laravel versions. Mine is Larav
4040
- Keep explanations brief and focused
4141
- Prioritize clarity over comprehensiveness for junior developers
4242

43+
===
4344

45+
<laravel-boost-guidelines>
46+
=== foundation rules ===
47+
48+
# Laravel Boost Guidelines
49+
50+
The Laravel Boost guidelines are specifically curated by Laravel maintainers for this application. These guidelines should be followed closely to enhance the user's satisfaction building Laravel applications.
51+
52+
## Foundational Context
53+
This application is a Laravel application and its main Laravel ecosystems package & versions are below. You are an expert with them all. Ensure you abide by these specific packages & versions.
54+
55+
- php - 8.4.10
56+
- laravel/framework (LARAVEL) - v12
57+
- laravel/prompts (PROMPTS) - v0
58+
- tightenco/ziggy (ZIGGY) - v2
59+
- laravel/pint (PINT) - v1
60+
- pestphp/pest (PEST) - v3
61+
- alpinejs (ALPINEJS) - v3
62+
- tailwindcss (TAILWINDCSS) - v4
63+
64+
65+
## Conventions
66+
- You must follow all existing code conventions used in this application. When creating or editing a file, check sibling files for the correct structure, approach, naming.
67+
- Use descriptive names for variables and methods. For example, `isRegisteredForDiscounts`, not `discount()`.
68+
- Check for existing components to reuse before writing a new one.
69+
70+
## Verification Scripts
71+
- Do not create verification scripts or tinker when tests cover that functionality and prove it works. Unit and feature tests are more important.
72+
73+
## Application Structure & Architecture
74+
- Stick to existing directory structure - don't create new base folders without approval.
75+
- Do not change the application's dependencies without approval.
76+
77+
## Frontend Bundling
78+
- If the user doesn't see a frontend change reflected in the UI, it could mean they need to run `npm run build`, `npm run dev`, or `composer run dev`. Ask them.
79+
80+
## Replies
81+
- Be concise in your explanations - focus on what's important rather than explaining obvious details.
82+
83+
## Documentation Files
84+
- You must only create documentation files if explicitly requested by the user.
85+
86+
87+
=== boost rules ===
88+
89+
## Laravel Boost
90+
- Laravel Boost is an MCP server that comes with powerful tools designed specifically for this application. Use them.
91+
92+
## Artisan
93+
- Use the `list-artisan-commands` tool when you need to call an Artisan command to double check the available parameters.
94+
95+
## URLs
96+
- Whenever you share a project URL with the user you should use the `get-absolute-url` tool to ensure you're using the correct scheme, domain / IP, and port.
97+
98+
## Tinker / Debugging
99+
- You should use the `tinker` tool when you need to execute PHP to debug code or query Eloquent models directly.
100+
- Use the `database-query` tool when you only need to read from the database.
101+
102+
## Reading Browser Logs With the `browser-logs` Tool
103+
- You can read browser logs, errors, and exceptions using the `browser-logs` tool from Boost.
104+
- Only recent browser logs will be useful - ignore old logs.
105+
106+
## Searching Documentation (Critically Important)
107+
- Boost comes with a powerful `search-docs` tool you should use before any other approaches. This tool automatically passes a list of installed packages and their versions to the remote Boost API, so it returns only version-specific documentation specific for the user's circumstance. You should pass an array of packages to filter on if you know you need docs for particular packages.
108+
- The 'search-docs' tool is perfect for all Laravel related packages, including Laravel, Inertia, Livewire, Filament, Tailwind, Pest, Nova, Nightwatch, etc.
109+
- You must use this tool to search for Laravel-ecosystem documentation before falling back to other approaches.
110+
- Search the documentation before making code changes to ensure we are taking the correct approach.
111+
- Use multiple, broad, simple, topic based queries to start. For example: `['rate limiting', 'routing rate limiting', 'routing']`.
112+
- Do not add package names to queries - package information is already shared. For example, use `test resource table`, not `filament 4 test resource table`.
113+
114+
### Available Search Syntax
115+
- You can and should pass multiple queries at once. The most relevant results will be returned first.
116+
117+
1. Simple Word Searches with auto-stemming - query=authentication - finds 'authenticate' and 'auth'
118+
2. Multiple Words (AND Logic) - query=rate limit - finds knowledge containing both "rate" AND "limit"
119+
3. Quoted Phrases (Exact Position) - query="infinite scroll" - Words must be adjacent and in that order
120+
4. Mixed Queries - query=middleware "rate limit" - "middleware" AND exact phrase "rate limit"
121+
5. Multiple Queries - queries=["authentication", "middleware"] - ANY of these terms
122+
123+
124+
=== php rules ===
125+
126+
## PHP
127+
128+
- Always use curly braces for control structures, even if it has one line.
129+
130+
### Constructors
131+
- Use PHP 8 constructor property promotion in `__construct()`.
132+
- <code-snippet>public function __construct(public GitHub $github) { }</code-snippet>
133+
- Do not allow empty `__construct()` methods with zero parameters.
134+
135+
### Type Declarations
136+
- Always use explicit return type declarations for methods and functions.
137+
- Use appropriate PHP type hints for method parameters.
138+
139+
<code-snippet name="Explicit Return Types and Method Params" lang="php">
140+
protected function isAccessible(User $user, ?string $path = null): bool
141+
{
142+
...
143+
}
144+
</code-snippet>
145+
146+
## Comments
147+
- Prefer PHPDoc blocks over comments. Never use comments within the code itself unless there is something _very_ complex going on.
148+
149+
## PHPDoc Blocks
150+
- Add useful array shape type definitions for arrays when appropriate.
151+
152+
## Enums
153+
- Typically, keys in an Enum should be TitleCase. For example: `FavoritePerson`, `BestLake`, `Monthly`.
154+
155+
156+
=== laravel/core rules ===
157+
158+
## Do Things the Laravel Way
159+
160+
- Use `php artisan make:` commands to create new files (i.e. migrations, controllers, models, etc.). You can list available Artisan commands using the `list-artisan-commands` tool.
161+
- If you're creating a generic PHP class, use `artisan make:class`.
162+
- Pass `--no-interaction` to all Artisan commands to ensure they work without user input. You should also pass the correct `--options` to ensure correct behavior.
163+
164+
### Database
165+
- Always use proper Eloquent relationship methods with return type hints. Prefer relationship methods over raw queries or manual joins.
166+
- Use Eloquent models and relationships before suggesting raw database queries
167+
- Avoid `DB::`; prefer `Model::query()`. Generate code that leverages Laravel's ORM capabilities rather than bypassing them.
168+
- Generate code that prevents N+1 query problems by using eager loading.
169+
- Use Laravel's query builder for very complex database operations.
170+
171+
### Model Creation
172+
- When creating new models, create useful factories and seeders for them too. Ask the user if they need any other things, using `list-artisan-commands` to check the available options to `php artisan make:model`.
173+
174+
### APIs & Eloquent Resources
175+
- For APIs, default to using Eloquent API Resources and API versioning unless existing API routes do not, then you should follow existing application convention.
176+
177+
### Controllers & Validation
178+
- Always create Form Request classes for validation rather than inline validation in controllers. Include both validation rules and custom error messages.
179+
- Check sibling Form Requests to see if the application uses array or string based validation rules.
180+
181+
### Queues
182+
- Use queued jobs for time-consuming operations with the `ShouldQueue` interface.
183+
184+
### Authentication & Authorization
185+
- Use Laravel's built-in authentication and authorization features (gates, policies, Sanctum, etc.).
186+
187+
### URL Generation
188+
- When generating links to other pages, prefer named routes and the `route()` function.
189+
190+
### Configuration
191+
- Use environment variables only in configuration files - never use the `env()` function directly outside of config files. Always use `config('app.name')`, not `env('APP_NAME')`.
192+
193+
### Testing
194+
- When creating models for tests, use the factories for the models. Check if the factory has custom states that can be used before manually setting up the model.
195+
- Faker: Use methods such as `$this->faker->word()` or `fake()->randomDigit()`. Follow existing conventions whether to use `$this->faker` or `fake()`.
196+
- When creating tests, make use of `php artisan make:test [options] <name>` to create a feature test, and pass `--unit` to create a unit test. Most tests should be feature tests.
197+
198+
### Vite Error
199+
- If you receive an "Illuminate\Foundation\ViteException: Unable to locate file in Vite manifest" error, you can run `npm run build` or ask the user to run `npm run dev` or `composer run dev`.
200+
201+
202+
=== laravel/v12 rules ===
203+
204+
## Laravel 12
205+
206+
- Use the `search-docs` tool to get version specific documentation.
207+
- Since Laravel 11, Laravel has a new streamlined file structure which this project uses.
208+
209+
### Laravel 12 Structure
210+
- No middleware files in `app/Http/Middleware/`.
211+
- `bootstrap/app.php` is the file to register middleware, exceptions, and routing files.
212+
- `bootstrap/providers.php` contains application specific service providers.
213+
- **No app\Console\Kernel.php** - use `bootstrap/app.php` or `routes/console.php` for console configuration.
214+
- **Commands auto-register** - files in `app/Console/Commands/` are automatically available and do not require manual registration.
215+
216+
### Database
217+
- When modifying a column, the migration must include all of the attributes that were previously defined on the column. Otherwise, they will be dropped and lost.
218+
- Laravel 11 allows limiting eagerly loaded records natively, without external packages: `$query->latest()->limit(10);`.
219+
220+
### Models
221+
- Casts can and likely should be set in a `casts()` method on a model rather than the `$casts` property. Follow existing conventions from other models.
222+
223+
224+
=== pint/core rules ===
225+
226+
## Laravel Pint Code Formatter
227+
228+
- You must run `vendor/bin/pint --dirty` before finalizing changes to ensure your code matches the project's expected style.
229+
- Do not run `vendor/bin/pint --test`, simply run `vendor/bin/pint` to fix any formatting issues.
230+
231+
232+
=== pest/core rules ===
233+
234+
## Pest
235+
236+
### Testing
237+
- If you need to verify a feature is working, write or update a Unit / Feature test.
238+
239+
### Pest Tests
240+
- All tests must be written using Pest. Use `php artisan make:test --pest <name>`.
241+
- You must not remove any tests or test files from the tests directory without approval. These are not temporary or helper files - these are core to the application.
242+
- Tests should test all of the happy paths, failure paths, and weird paths.
243+
- Tests live in the `tests/Feature` and `tests/Unit` directories.
244+
- Pest tests look and behave like this:
245+
<code-snippet name="Basic Pest Test Example" lang="php">
246+
it('is true', function () {
247+
expect(true)->toBeTrue();
248+
});
249+
</code-snippet>
250+
251+
### Running Tests
252+
- Run the minimal number of tests using an appropriate filter before finalizing code edits.
253+
- To run all tests: `php artisan test`.
254+
- To run all tests in a file: `php artisan test tests/Feature/ExampleTest.php`.
255+
- To filter on a particular test name: `php artisan test --filter=testName` (recommended after making a change to a related file).
256+
- When the tests relating to your changes are passing, ask the user if they would like to run the entire test suite to ensure everything is still passing.
257+
258+
### Pest Assertions
259+
- When asserting status codes on a response, use the specific method like `assertForbidden` and `assertNotFound` instead of using `assertStatus(403)` or similar, e.g.:
260+
<code-snippet name="Pest Example Asserting postJson Response" lang="php">
261+
it('returns all', function () {
262+
$response = $this->postJson('/api/docs', []);
263+
264+
$response->assertSuccessful();
265+
});
266+
</code-snippet>
267+
268+
### Mocking
269+
- Mocking can be very helpful when appropriate.
270+
- When mocking, you can use the `Pest\Laravel\mock` Pest function, but always import it via `use function Pest\Laravel\mock;` before using it. Alternatively, you can use `$this->mock()` if existing tests do.
271+
- You can also create partial mocks using the same import or self method.
272+
273+
### Datasets
274+
- Use datasets in Pest to simplify tests which have a lot of duplicated data. This is often the case when testing validation rules, so consider going with this solution when writing tests for validation rules.
275+
276+
<code-snippet name="Pest Dataset Example" lang="php">
277+
it('has emails', function (string $email) {
278+
expect($email)->not->toBeEmpty();
279+
})->with([
280+
'james' => '[email protected]',
281+
'taylor' => '[email protected]',
282+
]);
283+
</code-snippet>
284+
285+
286+
=== tailwindcss/core rules ===
287+
288+
## Tailwind Core
289+
290+
- Use Tailwind CSS classes to style HTML, check and use existing tailwind conventions within the project before writing your own.
291+
- Offer to extract repeated patterns into components that match the project's conventions (i.e. Blade, JSX, Vue, etc..)
292+
- Think through class placement, order, priority, and defaults - remove redundant classes, add classes to parent or child carefully to limit repetition, group elements logically
293+
- You can use the `search-docs` tool to get exact examples from the official documentation when needed.
294+
295+
### Spacing
296+
- When listing items, use gap utilities for spacing, don't use margins.
297+
298+
<code-snippet name="Valid Flex Gap Spacing Example" lang="html">
299+
<div class="flex gap-8">
300+
<div>Superior</div>
301+
<div>Michigan</div>
302+
<div>Erie</div>
303+
</div>
304+
</code-snippet>
305+
306+
307+
### Dark Mode
308+
- If existing pages and components support dark mode, new pages and components must support dark mode in a similar way, typically using `dark:`.
309+
310+
311+
=== tailwindcss/v4 rules ===
312+
313+
## Tailwind 4
314+
315+
- Always use Tailwind CSS v4 - do not use the deprecated utilities.
316+
- `corePlugins` is not supported in Tailwind v4.
317+
- In Tailwind v4, you import Tailwind using a regular CSS `@import` statement, not using the `@tailwind` directives used in v3:
318+
319+
<code-snippet name="Tailwind v4 Import Tailwind Diff" lang="diff"
320+
- @tailwind base;
321+
- @tailwind components;
322+
- @tailwind utilities;
323+
+ @import "tailwindcss";
324+
</code-snippet>
325+
326+
327+
### Replaced Utilities
328+
- Tailwind v4 removed deprecated utilities. Do not use the deprecated option - use the replacement.
329+
- Opacity values are still numeric.
330+
331+
| Deprecated | Replacement |
332+
|------------+--------------|
333+
| bg-opacity-* | bg-black/* |
334+
| text-opacity-* | text-black/* |
335+
| border-opacity-* | border-black/* |
336+
| divide-opacity-* | divide-black/* |
337+
| ring-opacity-* | ring-black/* |
338+
| placeholder-opacity-* | placeholder-black/* |
339+
| flex-shrink-* | shrink-* |
340+
| flex-grow-* | grow-* |
341+
| overflow-ellipsis | text-ellipsis |
342+
| decoration-slice | box-decoration-slice |
343+
| decoration-clone | box-decoration-clone |
344+
345+
346+
=== tests rules ===
347+
348+
## Test Enforcement
349+
350+
- Every change must be programmatically tested. Write a new test or update an existing test, then run the affected tests to make sure they pass.
351+
- Run the minimum number of tests needed to ensure code quality and speed. Use `php artisan test` with a specific filename or filter.
352+
</laravel-boost-guidelines>

‎.mcp.json‎

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
{
2+
"mcpServers": {
3+
"laravel-boost": {
4+
"command": "php",
5+
"args": [
6+
"./artisan",
7+
"boost:mcp"
8+
]
9+
}
10+
}
11+
}

0 commit comments

Comments
 (0)