filament

# AGENTS.md

This file provides guidance to coding agents working in this repository.

## Project Overview

Filament is a full-stack UI framework for Laravel built with Livewire. It provides admin panels, forms, tables, notifications, actions, infolists, and widgets as composable packages.

## Critical: Naming Conventions

### Variable Names

**Never use abbreviated variable names.** Use full descriptive names:

```php
// GOOD
$exception, $component, $response, $configuration, $record, $livewire

// BAD - never do this
$e, $comp, $res, $cfg, $rec, $lw
```

Only exception: universally understood abbreviations like `$id`, `$url`.

### Pest Test Names

**Always use backticks for code references. Add `()` for methods:**

```php
// GOOD
it('can use `aspectRatio()` to force image cropping')
it('returns `null` for `getImageCropAspectRatio()` by default')
it('validates `$record` is an instance of `Model`')

// BAD - missing backticks
it('can use aspectRatio to force image cropping')
it('returns null for getImageCropAspectRatio by default')
```

### Code Comments

**Use backticks when referencing code in comments:**

```php
// GOOD
// Uses `evaluate()` to resolve the `Closure`
// Returns `null` if the `$record` is not set

// BAD
// Uses evaluate() to resolve the Closure
```

## Development Commands

**Introduce new tests only for actual frontend or backend behavior changes.** Styling changes and bug fixes that restore existing intended behavior should not introduce new tests. Verify those fixes using existing tests and, for styling, visual inspection. For frontend behavior changes, add browser tests using Pest Browser with `visit()`. Always call `assertNoAccessibilityIssues()` in both light and dark modes (`->inDarkMode()`).

- Keep inexpensive non-browser coverage of supported configuration and rendering paths, including setters, getters, `Closure` evaluation, and successful rendering.
- In browser tests, do not assert exact translated copy, CSS classes, inline styles, utility classes, incidental HTML, or computed visual styling unless that output proves the behavior under test.
- Prefer stable semantic selectors or `data-testid` hooks for browser interactions. Do not use presentation classes or visible copy merely as readiness checks.
- Before adding a browser test, search the file for the same route and setup. Combine related assertions into one coherently named test and reuse the page; use another visit only when isolation or a state reset is required.
- Keep light- and dark-mode accessibility checks for the same scenario together. Do not repeat database, authentication, or browser setup solely to split those checks into separate tests.
- Keep each test focused on one behavior and each test file focused on its owning component or feature. Separate scenarios only when combining them would obscure the behavior or introduce order-dependent state.

```bash
composer test              # Run all tests (SQLite + commands + PHPStan)
composer test:sqlite       # Run tests with SQLite
composer test:mysql        # Run tests with MySQL
composer test:pgsql        # Run tests with PostgreSQL
composer test:phpstan      # Run PHPStan static analysis
composer cs                # Run all code style fixes (Rector + Pint + Prettier)

npm run build              # Build all JS and CSS
npm run build-demo         # Build and publish to ../demo if it exists

# Run a single test file
vendor/bin/pest tests/src/Forms/Components/FileUploadTest.php

# Run a single test by name
vendor/bin/pest --filter="it can use \`aspectRatio\(\)\` to force image cropping"
```

## Coding Patterns

### Fluent API

Components use `make()` constructor and fluent chainable methods. Nullable properties have nullable setters so they can be undone:

```php
TextInput::make('name')
    ->label('Full name')
    ->icon('heroicon-o-user')

// Property and setter share the same name, nullable to allow unsetting
protected string | Closure | null $icon = null;

public function icon(string | Closure | null $icon): static
{
    $this->icon = $icon;

    return $this;
}

// Getter prefixed with `get`, uses `evaluate()` for `Closure` support
public function getIcon(): ?string
{
    return $this->evaluate($this->icon);
}
```

### Boolean Methods

```php
// Property - `is`/`should`/`can`/`has` prefix, defaults `false`, supports `Closure`
protected bool | Closure $isDisabled = false;

// Setter - verb form, defaults `true`, pass `false` to undo
public function disabled(bool | Closure $condition = true): static
{
    $this->isDisabled = $condition;

    return $this;
}

// Getter - cast to `bool`
public function isDisabled(): bool
{
    return (bool) $this->evaluate($this->isDisabled);
}
```

### Static Closures

Use `static fn` when the closure doesn't use `$this`:

```php
->placeholder(static fn (Select $component): ?string => $component->isDisabled() ? null : 'Select...')
->visible(fn (): bool => $this->canView()) // Uses `$this`, cannot be static
```

### Container Resolution

Use `app()` instead of `new` to allow users to bind custom implementations:

```php
app(RelationshipJoiner::class)->prepareQuery($relationship) // Good
(new RelationshipJoiner())->prepareQuery($relationship)     // Avoid
```

### Extensibility

Do not use `final` or `readonly` classes - users need to extend Filament classes.

### Concerns and Contracts

Traits in `Concerns/` directories: `Can*` (capabilities), `Has*` (properties).
Interfaces in `Contracts/` directories.

## Coding Standards

### JavaScript lifecycle cleanup

- Alpine components and directives must release resources they own in `destroy()` or `cleanup()`, including listeners on surviving ancestors or global objects, observers, animation loops, and third-party instances. Listeners attached only to removed subtree elements do not need separate cleanup.
- Guard asynchronous initialization and callbacks when they could create surviving resources or cause observable stale behavior after destruction. Use the third-party instance's real teardown API, verified against its source when necessary.
- Do not add cleanup solely for short-lived timers; cancel or guard them when their callback could still cause stale behavior after destruction.

### PHPDoc

Only add when providing type info beyond native PHP types:

```php
/** @var array<string, array{label: string, icon: string}> */  // Good
/** @param string $name The name */                            // Redundant
```

### Deprecations

Keep old public methods used in docs, mark deprecated:

```php
/** @deprecated Use `newMethod()` instead. */
public function oldMethod(): void
{
    return $this->newMethod();
}
```

## Architecture

### Packages (`packages/`)

Core: **support** (base utilities) → **schemas** (UI layouts) → **forms**, **infolists**, **tables**, **actions**, **notifications**, **widgets** → **panels** (full admin framework)

Other: query-builder, upgrade, spatie-laravel-media-library-plugin, spatie-laravel-settings-plugin, spatie-laravel-tags-plugin, spatie-laravel-google-fonts-plugin, spark-billing-provider

### Key Classes

- **Resources** (`packages/panels/src/Resources/`): CRUD interfaces for Eloquent models
- **Pages** (`packages/panels/src/Pages/`): Livewire page components
- **Schema Components** (`packages/schemas/src/Components/`): Base UI components
- **Actions** (`packages/actions/src/`): Modal-based operations
- **Panel** (`packages/panels/src/Panel.php`): Admin panel configuration

### File Locations

- Tests: `tests/src/{Forms,Tables,Actions,Panels}/`
- Docs: `docs/` and `packages/{package}/docs/`
- Views: `packages/{package}/resources/views/`
- CSS: `packages/{package}/resources/css/`
- Translations: `packages/{package}/resources/lang/{locale}/`

### CSS Hook Classes

**Never use Tailwind classes directly in Blade views.** All Tailwind classes must be in CSS files using `@apply`:

```css
.fi-fo-field {
    @apply grid gap-y-2;
}
```

Hook class naming:
- Prefix: `fi-` with package codes (`fi-fo-` forms, `fi-ta-` tables, `fi-ac-` actions, etc.)
- Abbreviations: `btn`, `col`, `ctn`, `wrp`

## Writing Documentation

**Always update documentation for user-facing features** in `packages/{package}/docs/`.

- **Tone**: Direct, second person ("You may set...", "You can do this using...")
- **Structure**: Start with `## Introduction`, show simplest code first
- **Section order**: Review the full page and analogous pages, then place sections by reader importance and logical flow, not by when they were added. Do not default new sections to the top.
- **Hierarchy**: Keep foundational and common workflows before specialized content, and nest narrower topics under their parent section.
- **Headings**: Use gerunds ("Setting the type" not "Type settings", "Enabling search" not "Search")
- **Formatting**: Backticks for code (`method()`, `ClassName`), include `use` statements
- **Asides**: `<Aside variant="tip|info|danger">...</Aside>`

### Documentation Screenshots

Screenshots are in `docs-assets/screenshots/`. To add new screenshots:

1. **Add component examples** to the appropriate Livewire component in `docs-assets/app/app/Livewire/` (e.g., `Schemas/LayoutDemo.php`). Give each example a unique `->id()` for the selector:
   ```php
   Group::make()
       ->id('myComponent')
       ->extraAttributes(['class' => 'p-16 max-w-2xl'])
       ->schema([
           // Your component here
       ]),
   ```

2. **Add screenshot definitions** to `docs-assets/screenshots/schema.js`:
   ```js
   'schemas/layout/my-component/simple': {
       url: 'schemas/layout',
       selector: '#myComponent',
       viewport: { width: 1920, height: 640, deviceScaleFactor: 3 },
   },
   ```

3. **Build assets** if you changed any CSS or JS files. Two builds are required — the repo root compiles each package's dist output, and the docs app has its own Vite build that bundles those outputs into `docs-assets/app/public/build/`. Skipping the second step leaves the docs app serving stale CSS, and screenshots will render against pre-change styles:
   ```bash
   # Terminal 1: compile package dist output
   npm run build

   # Terminal 2: bundle the docs app's CSS from the package output
   cd docs-assets/app && npm run build
   ```
   If you also changed the Livewire demo or Blade views, clear caches afterwards: `cd docs-assets/app && php artisan optimize:clear`.

4. **Generate screenshots**:
   ```bash
   # Terminal 1: Start the app server (must use default port 8000)
   cd docs-assets/app && php artisan serve

   # Terminal 2: Run from the screenshots directory
   cd docs-assets/screenshots
   export PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true
   export PUPPETEER_EXECUTABLE_PATH=$(which chromium)
   node script.js "schemas/layout/my-component/*"  # Filter pattern
   node script.js --parallel "tables/*"            # Process in parallel (add =N for a specific worker count)
   ```

   **Important:** The script expects `http://127.0.0.1:8000`. Don't use a custom port.

   **Important:** Set up the app first with `php artisan migrate:fresh --seed && php artisan storage:link` — seeding also copies the file upload demos' sample images from `database/seed-images/` to the `public` disk.

   `--parallel` starts its own servers on ports 8001+ (no `php artisan serve` needed), each with its own copy of the seeded database, because many demos mutate the database on mount and would corrupt each other's screenshots if they shared one. The pristine database is restored before every page load, so each screenshot always sees freshly seeded data — this makes parallel mode the most reliable way to run large batches (in serial mode, a demo that truncates tables can 404 later entries, e.g. tenancy or resource pages, until you reseed). Screenshots using the `configure` option run serially after the parallel pool because they mutate a PHP file shared by every server.

   Schema entries without a `before` callback that share the same URL, viewport, and theme are captured from a single page load, and one browser process is shared across the whole run. If an entry needs an isolated page load (e.g. its demo mutates state when rendered), give it a `before` callback.

   Pages are captured with `prefers-reduced-motion: reduce` and with CSS animations, transitions, and the input caret disabled, so screenshots never depend on which animation frame they caught (e.g. spinning loading indicators, modal fade-ins, caret blinking).

5. **Use in docs** with `<AutoScreenshot name="schemas/layout/my-component/simple" alt="Description" version="4.x" />`

Screenshots are generated in `images/light/` and `images/dark/`. Use natural, realistic content - not test-like examples.

More agent context in filamentphp/filament

One other file this repository gives its agents.