Laravel Boost Guidelines

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.

Foundational Context

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.

• php - 8.4.21
• filament/filament (FILAMENT) - v4
• laravel/framework (LARAVEL) - v12
• laravel/prompts (PROMPTS) - v0
• laravel/sanctum (SANCTUM) - v4
• livewire/livewire (LIVEWIRE) - v3
• laravel/mcp (MCP) - v0
• laravel/pint (PINT) - v1
• laravel/sail (SAIL) - v1
• pestphp/pest (PEST) - v4
• phpunit/phpunit (PHPUNIT) - v12
• alpinejs (ALPINEJS) - v3
• prettier (PRETTIER) - v3
• tailwindcss (TAILWINDCSS) - v4

Conventions

• 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, and naming.
• Use descriptive names for variables and methods. For example, isRegisteredForDiscounts, not discount().
• Check for existing components to reuse before writing a new one.

Verification Scripts

• Do not create verification scripts or tinker when tests cover that functionality and prove it works. Unit and feature tests are more important.

Application Structure & Architecture

• Stick to existing directory structure; don't create new base folders without approval.
• Do not change the application's dependencies without approval.

Frontend Bundling

• 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.

Replies

• Be concise in your explanations - focus on what's important rather than explaining obvious details.

Documentation Files

• You must only create documentation files if explicitly requested by the user.

=== boost rules ===

Laravel Boost

• Laravel Boost is an MCP server that comes with powerful tools designed specifically for this application. Use them.

Artisan

• Use the list-artisan-commands tool when you need to call an Artisan command to double-check the available parameters.

URLs

• 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.

Tinker / Debugging

• You should use the tinker tool when you need to execute PHP to debug code or query Eloquent models directly.
• Use the database-query tool when you only need to read from the database.

Reading Browser Logs With the browser-logs Tool

• You can read browser logs, errors, and exceptions using the browser-logs tool from Boost.
• Only recent browser logs will be useful - ignore old logs.

Searching Documentation (Critically Important)

• Boost comes with a powerful search-docs tool you should use before any other approaches when dealing with Laravel or Laravel ecosystem packages. This tool automatically passes a list of installed packages and their versions to the remote Boost API, so it returns only version-specific documentation for the user's circumstance. You should pass an array of packages to filter on if you know you need docs for particular packages.
• The search-docs tool is perfect for all Laravel-related packages, including Laravel, Inertia, Livewire, Filament, Tailwind, Pest, Nova, Nightwatch, etc.
• You must use this tool to search for Laravel ecosystem documentation before falling back to other approaches.
• Search the documentation before making code changes to ensure we are taking the correct approach.
• Use multiple, broad, simple, topic-based queries to start. For example: ['rate limiting', 'routing rate limiting', 'routing'].
• Do not add package names to queries; package information is already shared. For example, use test resource table, not filament 4 test resource table.

Available Search Syntax

• You can and should pass multiple queries at once. The most relevant results will be returned first.

1. Simple Word Searches with auto-stemming - query=authentication - finds 'authenticate' and 'auth'.
2. Multiple Words (AND Logic) - query=rate limit - finds knowledge containing both "rate" AND "limit".
3. Quoted Phrases (Exact Position) - query="infinite scroll" - words must be adjacent and in that order.
4. Mixed Queries - query=middleware "rate limit" - "middleware" AND exact phrase "rate limit".
5. Multiple Queries - queries=["authentication", "middleware"] - ANY of these terms.

=== php rules ===

PHP

• Always use curly braces for control structures, even if it has one line.

Constructors

• Use PHP 8 constructor property promotion in __construct().
  • public function __construct(public GitHub $github) { }
• Do not allow empty __construct() methods with zero parameters unless the constructor is private.

Type Declarations

• Always use explicit return type declarations for methods and functions.
• Use appropriate PHP type hints for method parameters.

Comments

• Prefer PHPDoc blocks over inline comments. Never use comments within the code itself unless there is something very complex going on.

PHPDoc Blocks

• Add useful array shape type definitions for arrays when appropriate.

Enums

• Typically, keys in an Enum should be TitleCase. For example: FavoritePerson, BestLake, Monthly.

=== laravel/core rules ===

Do Things the Laravel Way

• 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.
• If you're creating a generic PHP class, use php artisan make:class.
• 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.

Database

• Always use proper Eloquent relationship methods with return type hints. Prefer relationship methods over raw queries or manual joins.
• Use Eloquent models and relationships before suggesting raw database queries.
• Avoid DB::; prefer Model::query(). Generate code that leverages Laravel's ORM capabilities rather than bypassing them.
• Generate code that prevents N+1 query problems by using eager loading.
• Use Laravel's query builder for very complex database operations.

Model Creation

• 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.

APIs & Eloquent Resources

• For APIs, default to using Eloquent API Resources and API versioning unless existing API routes do not, then you should follow existing application convention.

Controllers & Validation

• Always create Form Request classes for validation rather than inline validation in controllers. Include both validation rules and custom error messages.
• Check sibling Form Requests to see if the application uses array or string based validation rules.

Queues

• Use queued jobs for time-consuming operations with the ShouldQueue interface.

Authentication & Authorization

• Use Laravel's built-in authentication and authorization features (gates, policies, Sanctum, etc.).

URL Generation

• When generating links to other pages, prefer named routes and the route() function.

Configuration

• 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').

Testing

• 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.
• Faker: Use methods such as $this->faker->word() or fake()->randomDigit(). Follow existing conventions whether to use $this->faker or fake().
• 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.

Vite Error

• 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.

=== laravel/v12 rules ===

Laravel 12

• Use the search-docs tool to get version-specific documentation.
• Since Laravel 11, Laravel has a new streamlined file structure which this project uses.

Laravel 12 Structure

• In Laravel 12, middleware are no longer registered in app/Http/Kernel.php.
• Middleware are configured declaratively in bootstrap/app.php using Application::configure()->withMiddleware().
• bootstrap/app.php is the file to register middleware, exceptions, and routing files.
• bootstrap/providers.php contains application specific service providers.
• The app\Console\Kernel.php file no longer exists; use bootstrap/app.php or routes/console.php for console configuration.
• Console commands in app/Console/Commands/ are automatically available and do not require manual registration.

Database

• 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.
• Laravel 12 allows limiting eagerly loaded records natively, without external packages: $query->latest()->limit(10);.

Models

• 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.

=== livewire/core rules ===

Livewire

• Use the search-docs tool to find exact version-specific documentation for how to write Livewire and Livewire tests.
• Use the php artisan make:livewire [Posts\CreatePost] Artisan command to create new components.
• State should live on the server, with the UI reflecting it.
• All Livewire requests hit the Laravel backend; they're like regular HTTP requests. Always validate form data and run authorization checks in Livewire actions.

Livewire Best Practices

• Livewire components require a single root element.

• Use wire:loading and wire:dirty for delightful loading states.

• Add wire:key in loops:

  @foreach ($items as $item)
      <div wire:key="item-{{ $item->id }}">
          {{ $item->name }}
      </div>
  @endforeach
  

• Prefer lifecycle hooks like mount(), updatedFoo() for initialization and reactive side effects:

Testing Livewire

=== livewire/v3 rules ===

Livewire 3

Key Changes From Livewire 2

• These things changed in Livewire 3, but may not have been updated in this application. Verify this application's setup to ensure you conform with application conventions.
  • Use wire:model.live for real-time updates, wire:model is now deferred by default.
  • Components now use the App\Livewire namespace (not App\Http\Livewire).
  • Use $this->dispatch() to dispatch events (not emit or dispatchBrowserEvent).
  • Use the components.layouts.app view as the typical layout path (not layouts.app).

New Directives

• wire:show, wire:transition, wire:cloak, wire:offline, wire:target are available for use. Use the documentation to find usage examples.

Alpine

• Alpine is now included with Livewire; don't manually include Alpine.js.
• Plugins included with Alpine: persist, intersect, collapse, and focus.

Lifecycle Hooks

• You can listen for livewire:init to hook into Livewire initialization, and fail.status === 419 for the page expiring:

Livewire.hook('message.failed', (message, component) => {
    console.error(message);
});

});

=== pint/core rules ===

Laravel Pint Code Formatter

• You must run vendor/bin/pint --dirty --format agent before finalizing changes to ensure your code matches the project's expected style.
• Do not run vendor/bin/pint --test --format agent, simply run vendor/bin/pint --format agent to fix any formatting issues.

=== pest/core rules ===

Pest

Testing

• If you need to verify a feature is working, write or update a Unit / Feature test.

Pest Tests

• All tests must be written using Pest. Use php artisan make:test --pest {name}.
• 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.
• Tests should test all of the happy paths, failure paths, and weird paths.
• Tests live in the tests/Feature and tests/Unit directories.
• Pest tests look and behave like this:

it('is true', function () { expect(true)->toBeTrue(); });

Running Tests

• Run the minimal number of tests using an appropriate filter before finalizing code edits.
• To run all tests: php artisan test --compact.
• To run all tests in a file: php artisan test --compact tests/Feature/ExampleTest.php.
• To filter on a particular test name: php artisan test --compact --filter=testName (recommended after making a change to a related file).
• 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.

Pest Assertions

• When asserting status codes on a response, use the specific method like assertForbidden and assertNotFound instead of using assertStatus(403) or similar, e.g.:

it('returns all', function () { $response = $this->postJson('/api/docs', []);

$response->assertSuccessful();

});

Mocking

• Mocking can be very helpful when appropriate.
• 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.
• You can also create partial mocks using the same import or self method.

Datasets

• Use datasets in Pest to simplify tests that have a lot of duplicated data. This is often the case when testing validation rules, so consider this solution when writing tests for validation rules.

=== pest/v4 rules ===

Pest 4

• Pest 4 is a huge upgrade to Pest and offers: browser testing, smoke testing, visual regression testing, test sharding, and faster type coverage.
• Browser testing is incredibly powerful and useful for this project.
• Browser tests should live in tests/Browser/.
• Use the search-docs tool for detailed guidance on utilizing these features.

Browser Testing

• You can use Laravel features like Event::fake(), assertAuthenticated(), and model factories within Pest 4 browser tests, as well as RefreshDatabase (when needed) to ensure a clean state for each test.
• Interact with the page (click, type, scroll, select, submit, drag-and-drop, touch gestures, etc.) when appropriate to complete the test.
• If requested, test on multiple browsers (Chrome, Firefox, Safari).
• If requested, test on different devices and viewports (like iPhone 14 Pro, tablets, or custom breakpoints).
• Switch color schemes (light/dark mode) when appropriate.
• Take screenshots or pause tests for debugging when appropriate.

Example Tests

$this->actingAs(User::factory()->create());

$page = visit('/sign-in'); // Visit on a real browser...

$page->assertSee('Sign In')
    ->assertNoJavascriptErrors() // or ->assertNoConsoleLogs()
    ->click('Forgot Password?')
    ->fill('email', 'nuno@laravel.com')
    ->click('Send Reset Link')
    ->assertSee('We have emailed your password reset link!')

Notification::assertSent(ResetPassword::class);

});

$pages->assertNoJavascriptErrors()->assertNoConsoleLogs();

=== tailwindcss/core rules ===

Tailwind CSS

• Use Tailwind CSS classes to style HTML; check and use existing Tailwind conventions within the project before writing your own.
• Offer to extract repeated patterns into components that match the project's conventions (i.e. Blade, JSX, Vue, etc.).
• Think through class placement, order, priority, and defaults. Remove redundant classes, add classes to parent or child carefully to limit repetition, and group elements logically.
• You can use the search-docs tool to get exact examples from the official documentation when needed.

Spacing

• When listing items, use gap utilities for spacing; don't use margins.

Dark Mode

• If existing pages and components support dark mode, new pages and components must support dark mode in a similar way, typically using dark:.

=== tailwindcss/v4 rules ===

Tailwind CSS 4

• Always use Tailwind CSS v4; do not use the deprecated utilities.
• corePlugins is not supported in Tailwind v4.
• In Tailwind v4, configuration is CSS-first using the @theme directive — no separate tailwind.config.js file is needed.

• In Tailwind v4, you import Tailwind using a regular CSS @import statement, not using the @tailwind directives used in v3:

Replaced Utilities

• Tailwind v4 removed deprecated utilities. Do not use the deprecated option; use the replacement.
• Opacity values are still numeric.

| Deprecated | Replacement | |------------+--------------| | bg-opacity-* | bg-black/* | | text-opacity-* | text-black/* | | border-opacity-* | border-black/* | | divide-opacity-* | divide-black/* | | ring-opacity-* | ring-black/* | | placeholder-opacity-* | placeholder-black/* | | flex-shrink-* | shrink-* | | flex-grow-* | grow-* | | overflow-ellipsis | text-ellipsis | | decoration-slice | box-decoration-slice | | decoration-clone | box-decoration-clone |

=== filament/filament rules ===

Filament

• Filament is a Laravel UI framework built on Livewire, Alpine.js, and Tailwind CSS. UIs are defined in PHP via fluent, chainable components. Follow existing conventions in this app.
• Use the search-docs tool for official documentation on Artisan commands, code examples, testing, relationships, and idiomatic practices. If search-docs is unavailable, refer to https://filamentphp.com/docs.

Artisan

• Always use Filament-specific Artisan commands to create files. Find available commands with the list-artisan-commands tool, or run php artisan --help.
• Inspect required options before running, and always pass --no-interaction.

Patterns

Always use static make() methods to initialize components. Most configuration methods accept a Closure for dynamic values.

Use Get $get to read other form field values for conditional logic:

Select::make('type') ->options(CompanyType::class) ->required() ->live(),

TextInput::make('company_name') ->required() ->visible(fn (Get $get): bool => $get('type') === 'business'),

Use Set $set inside ->afterStateUpdated() on a ->live() field to mutate another field reactively. Prefer ->live(onBlur: true) on text inputs to avoid per-keystroke updates:

TextInput::make('title') ->required() ->live(onBlur: true) ->afterStateUpdated(fn (Set $set, ?string $state) => $set( 'slug', Str::slug($state ?? ''), )),

TextInput::make('slug') ->required(),

Compose layout by nesting Section and Grid. Children need explicit ->columnSpan() or ->columnSpanFull():

Section::make('Details') ->schema([ Grid::make(2)->schema([ TextInput::make('first_name') ->columnSpan(1), TextInput::make('last_name') ->columnSpan(1), TextInput::make('bio') ->columnSpanFull(), ]), ]),

Use Repeater for inline HasMany management. ->relationship() with no args binds to the relationship matching the field name:

Repeater::make('qualifications') ->relationship() ->schema([ TextInput::make('institution') ->required(), TextInput::make('qualification') ->required(), ]) ->columns(2),

Use state() with a Closure to compute derived column values:

TextColumn::make('full_name') ->state(fn (User $record): string => "{$record->first_name} {$record->last_name}"),

Use SelectFilter for enum or relationship filters, and Filter with a ->query() closure for custom logic:

SelectFilter::make('status') ->options(UserStatus::class),

SelectFilter::make('author') ->relationship('author', 'name'),

Filter::make('verified') ->query(fn (Builder $query) => $query->whereNotNull('email_verified_at')),

Actions are buttons that encapsulate optional modal forms and behavior:

Action::make('updateEmail') ->schema([ TextInput::make('email') ->email() ->required(), ]) ->action(fn (array $data, User $record) => $record->update($data)),

Testing

Testing setup (requires pestphp/pest-plugin-livewire in composer.json):

• Always call $this->actingAs(User::factory()->create()) before testing panel functionality.
• For edit pages, pass ['record' => $user->id], use ->call('save') (not ->call('create')), and do not assert ->assertRedirect() (edit pages do not redirect after save).

livewire(ListUsers::class) ->assertCanSeeTableRecords($users) ->searchTable($users->first()->name) ->assertCanSeeTableRecords($users->take(1)) ->assertCanNotSeeTableRecords($users->skip(1));

livewire(CreateUser::class) ->fillForm([ 'name' => 'Test', 'email' => 'test@example.com', ]) ->call('create') ->assertNotified() ->assertHasNoFormErrors() ->assertRedirect();

assertDatabaseHas(User::class, [ 'name' => 'Test', 'email' => 'test@example.com', ]);

assertDatabaseHas(User::class, [ 'id' => $user->id, 'name' => 'Updated', ]);

Use ->callAction(DeleteAction::class) for page actions, or ->callAction(TestAction::make('name')->table($record)) for table actions:

livewire(ListUsers::class) ->callAction(TestAction::make('promote')->table($user), [ 'role' => 'admin', ]) ->assertNotified();

Correct Namespaces

• Form fields (TextInput, Select, Repeater, etc.): Filament\Forms\Components\
• Infolist entries (TextEntry, IconEntry, etc.): Filament\Infolists\Components\
• Layout components (Grid, Section, Fieldset, Tabs, Wizard, etc.): Filament\Schemas\Components\
• Schema utilities (Get, Set, etc.): Filament\Schemas\Components\Utilities\
• Table columns (TextColumn, IconColumn, etc.): Filament\Tables\Columns\
• Table filters (SelectFilter, Filter, etc.): Filament\Tables\Filters\
• Actions (DeleteAction, CreateAction, etc.): Filament\Actions\. Never use Filament\Tables\Actions\, Filament\Forms\Actions\, or any other sub-namespace for actions.
• Icons: Filament\Support\Icons\Heroicon enum (e.g., Heroicon::PencilSquare)

Common Mistakes

• Never assume public file visibility. File visibility is private by default. Always use ->visibility('public') when public access is needed.
• Never assume full-width layout. Grid, Section, Fieldset, and Repeater do not span all columns by default.
• Use Select::make('author_id')->relationship('author', 'name') for BelongsTo fields. BelongsToSelect does not exist in v4.
• Repeater uses ->schema(), not ->fields().
• Never add ->dehydrated(false) to fields that need to be saved. It strips the value from form state before ->action() or the save handler runs. Only use it for helper/UI-only fields.
• Use correct property types when overriding Page, Resource, and Widget properties. These properties have union types or changed modifiers that must be preserved:
  • $navigationIcon: protected static string | BackedEnum | null (not ?string)
  • $navigationGroup: protected static string | UnitEnum | null (not ?string)
  • $view: protected string (not protected static string) on Page and Widget classes

=== prism-php/prism rules ===

Prism

• Prism is a Laravel package for integrating Large Language Models (LLMs) into applications with a fluent, expressive and eloquent API.
• Prism supports multiple AI providers: OpenAI, Anthropic, Ollama, Mistral, Groq, XAI, Gemini, VoyageAI, ElevenLabs, DeepSeek, and OpenRouter, Amazon Bedrock.
• Always use the Prism facade, class, or prism() helper function for all LLM interactions.
• Prism documentation follows the llms.txt format for its docs website and its hosted at https://prismphp.com/**
• Before implementing any features using Prism, use the web-search tool to get the latest docs for that specific feature. The docs listing is available in

Basic Usage Patterns

• Use Prism::text() for text generation, Prism::structured() for structured output, Prism::embeddings() for embeddings, Prism::image() for image generation, and Prism::audio() for audio processing.
• Always chain the using() method to specify provider and model before generating responses.
• Use asText(), asStructured(), asStream(), asEmbeddings(), etc. to finalize the request based on the desired response type.
• You can also use the fluent prism() helper function as an alternative to the Prism facade.

Core Concepts

• [**/core-concepts/text-generation.md] Use these docs for complete guide to text generation including basic usage patterns, the fluent API, provider/model selection, prompt engineering, max tokens configuration, temperature settings, and response handling
• [**/core-concepts/streaming-output.md] Use these docs for streaming responses in real-time, handling chunked output, streaming event types, and streaming response types
• [**/core-concepts/tools-function-calling.md] Use these docs for comprehensive tool/function calling functionality, defining tools with JSON schemas, registering handler functions, multi-step tool execution, error handling in tools, and provider-specific tool calling capabilities
• [**/core-concepts/structured-output.md] Use these docs for generating structured JSON output, defining schemas and handling structured responses across different providers
• [**/core-concepts/embeddings.md] Use these docs for creating vector embeddings from text and documents, choosing embedding models, and use cases like semantic search and similarity matching
• [**/core-concepts/image-generation.md] Use these docs for generating images from text prompts, configuring image size and quality, working with different image models and handling image responses
• [**/core-concepts/audio.md] Use these docs for audio processing including text-to-speech (TTS) synthesis, speech-to-text (STT) transcription, voice selection, audio format options, and handling audio files
• [**/core-concepts/schemas.md] Use these docs for defining and working with schemas for structured output, JSON schema specifications
• [**/core-concepts/prism-server.md] Use these docs for setting up and using Prism Server, Prism Server is a powerful feature that allows you to expose your Prism-powered AI models through a standardized API.
• [**/core-concepts/testing.md] Use these docs for testing Prism integrations avoiding real API calls in tests, and assertion helpers

Input Modalities

• [**/input-modalities/images.md] Use these docs for passing images as input to LLMs, supporting multiple image formats
• [**/input-modalities/documents.md] Use these docs for processing documents (PDFs, Word docs, etc.) as input, document parsing and text extraction
• [**/input-modalities/audio.md] Use these docs for using audio files as input, audio transcription to text, supported audio formats
• [**/input-modalities/video.md] Use these docs for working with video input for supporting providers.

Providers

• [**/providers/anthropic.md] Use these docs for Anthropic (Claude) provider and provider-specific parameters
• [**/providers/deepseek.md] Use these docs for DeepSeek provider and provider-specific parameters
• [**/providers/elevenlabs.md] Use these docs for ElevenLabs text-to-speech provider and provider-specific parameters
• [**/providers/gemini.md] Use these docs for Google Gemini provider and provider-specific parameters
• [**/providers/groq.md] Use these docs for Groq provider setup and provider-specific parameters
• [**/providers/mistral.md] Use these docs for Mistral AI provider and provider-specific parameters
• [**/providers/ollama.md] Use these docs for Ollama local LLM provider and provider-specific parameters
• [**/providers/openai.md] Use these docs for OpenAI provider and provider-specific parameters
• [**/providers/openrouter.md] Use these docs for OpenRouter provider and provider-specific parameters
• [**/providers/voyageai.md] Use these docs for VoyageAI embeddings provider and provider-specific parameters
• [**/providers/xai.md] Use these docs for XAI (Grok) provider and provider-specific parameters

Advanced

• [**/advanced/error-handling.md] Use these docs for error handling strategies,
• [**/advanced/custom-providers.md] Use these docs for creating custom provider implementations, extending the Provider base class, implementing required methods (text, stream, structured, embeddings)
• [**/advanced/rate-limits.md] Use these docs for managing API rate limits across providers.
• [**/advanced/provider-interoperability.md] Use these docs for switching between providers seamlessly, writing provider-agnostic code

Prism Relay (Model Context Protocol Integration) (https://github.com/prism-php/relay)

Prism Bedrock (AWS Bedrock Provider) (https://github.com/prism-php/bedrock)

Contributing

Suggesting a new package

• If you want a package to be added, first make sure it does not already exist in the database via the search function in the website, and then if that's the case please open a new discussion. You'll get a reply when we add your suggested package to the database.

Adding a new package

• If you want to PR a new package, you can clone the repo locally and visit the /admin with these credentials:

  Email: admin@admin.com
  Password: admin
  

• If you decide to PR a package to be added, please include as many packages as you can in a single PR. Don't open a PR for each package.
• Make sure none of the information provided use any foul language.

Bugfixes or new features

• Feel free to open an issue or a pull request to add a new feature or fix a bug.

How do we choose packages?

• The criteria for a package to be added is somewhat opinionated and is a mixture of some guidelines and rules we've set for ourselves.
• Our goal is not to include every package out there, but to include the ones that are useful and actively maintained.
• We try to avoid including commercial/paid packages.
• The number of stars on GitHub is not a factor in deciding whether to include a package or not. We may include a package with less than 5 stars, and we may not include a package with +5k stars.
• If you see us add a highly starred suggested package right away, and we reject your package with few stars, it's probably because your package is very new and is not proven to be useful to the community yet. Still we might re-visit your package in the future and add it later.
• We may remove packages that do not support recent versions of Laravel and PHP.
• The word "new" which we used in the title and description of the website does not necessarily refer to the release date of the package, but to the fact that it's new to the community member who's discovering it. So if you just published a new package and would like it would be added, we may not simply add it right away.

🌸 Please don't have any hard feelings if we're not including your package in the database ^_^

💙 We love you and we appreciate your work and efforts.

If you decide to suggest a package you can create a new discussion in the "Package Suggestions" category.

Notes for package creators/owners

• If the information about your package is incorrect, please let us know and we'll fix it right away.
• If for any reason you want to remove your package from the database, please open an issue or ask in discussions. We'll remove it as soon as possible.