Filament Table Repeater Laravel Package

Getting Started

Install and confirm version fit first.

composer require icetalker/filament-table-repeater

Before writing a single line of schema, check the Filament major version in the target app. If it's v4, stop — Filament's native Repeater has a table() method and the README itself points you there. This package is a v3 tool. Adopting it on v4 is buying a migration.

Pin the package explicitly rather than floating a caret across the 2.x line:

"icetalker/filament-table-repeater": "^2.0.4"

v2.0.4 is the release described only as "fix reorder." Treat earlier 2.0.x pins as suspect for anything where row order is persisted and business-meaningful.

First place to look. Not the README — open Icetalker\FilamentTableRepeater\Forms\Components\TableRepeater in vendor/ and read the class top to bottom. It's short, it extends Repeater, and the only things it actually overrides are the view and the colStyles surface. That two-minute read tells you more than the docs about what's inherited and what's replaced.

Publish views only if you need theming control. The publish is a one-way door into owning CSS maintenance:

php artisan vendor:publish --tag="filament-table-repeater"

Default to not publishing. Publish when a designer hands you a spec the defaults can't satisfy.

First use case. Pick a form where the data is genuinely rectangular — line items with a fixed column set (product, quantity, unit price, total). Swap the class, keep everything else:

use Icetalker\FilamentTableRepeater\Forms\Components\TableRepeater;

TableRepeater::make('items')
    ->relationship('items')
    ->schema([
        Forms\Components\TextInput::make('product')->required(),
        Forms\Components\TextInput::make('quantity')->numeric()->default(1),
        Forms\Components\TextInput::make('unit_price')->numeric()->prefix('$'),
    ])
    ->reorderable()
    ->cloneable()
    ->minItems(1)
    ->maxItems(20),

If that renders and saves, you've validated the core integration in under an hour.

Implementation Patterns

Wrap it, don't sprinkle it. Every usage should go through one internal component so the eventual exit (Filament v4 table(), or back to stock Repeater) is a single-file edit rather than a grep across the codebase:

namespace App\Forms\Components;

use Icetalker\FilamentTableRepeater\Forms\Components\TableRepeater;

class LineItemRepeater extends TableRepeater
{
    protected function setUp(): void
    {
        parent::setUp();

        $this->reorderable()->cloneable()->minItems(1);
    }
}

Consumer schemas then reference LineItemRepeater::make('items') and know nothing about the vendor.

Column styling is your main layout lever. With inset(), grid(), and columns() off the table, colStyles() is how you actually control width and emphasis. Key it by field name, and use the Closure form when the styling depends on state:

->colStyles([
    'product'    => 'width: 40%;',
    'quantity'   => 'width: 100px; text-align: right;',
    'unit_price' => 'width: 140px;',
])

Note the v1.3.0 CSS class rename (filament-table-repeater-header-cell → it-table-repeater-cell-label, filament-table-repeater-tbody-cell → it-table-repeater-cell). If you publish views, target the it- prefixed selectors — the old names are gone.

Relationship binding is inherited and behaves like stock Repeater. ->relationship('items') handles load, save, and delete. The persisted shape is identical to a normal Repeater, which is exactly what makes the exit cheap. Do not build any product logic that depends on the table rendering — the data layer is upstream Filament's and will survive the swap.

Reorderable rows need a persistence check, not a visual check. Drag-and-drop can look correct in the browser and still write the wrong order. After the first integration, do this:

1. Create three rows, drag row 3 to position 1.
2. Save.
3. Reload the page.
4. Query the database directly and inspect the order column.

If step 4 disagrees with step 3, you're on a broken pin — escalate rather than working around it.

Compose with a Grid wrapper when you need surrounding layout. Since the component can't do its own grid, wrap it:

Forms\Components\Grid::make(1)->schema([
    TableRepeater::make('items')->...,
    Forms\Components\Textarea::make('notes'),
])

Guard the Filament major version in CI. The real compatibility surface isn't this package, it's the Filament major it subclasses. Add a constraint on filament/filament in the same PR, or a CI check that fails on a Filament 4 resolution. A routine composer update that lifts Filament to v4 will break the subclass contract silently.

Gotchas and Tips

inset(), grid(), and columns() are gone. They exist on Repeater and will appear to be available on TableRepeater via inheritance, but the table renderer doesn't honor them. The failure mode is late and quiet: your layout just looks wrong during QA, not at design review. Screen for these at spec time, not build time.

The last-release metadata is ahead of today's date. Any dependency review or security attestation that reads a 2026-09-20 release date should verify against Packagist directly. Treat it as a data-quality item, not a package defect — but don't cite it in a compliance artifact without checking.

Single maintainer, zero dependents, one-line changelogs. "fix reorder," "fix parameter missing of relative()." No linked issues, no diff narrative, no second committer. This is not a reason to avoid the package for a low-stakes admin form, but it is a reason to have a named owner and an exit rehearsal. Do not fork it — the fork inherits the same upstream-obsolescence problem with none of the maintainer's future work.

Version pin discipline is the whole risk story. The 2.0.x line had a reorder defect fixed only in 2.0.4, with no description of what was broken or which versions were affected. If any environment in your fleet runs 2.0.0–2.0.3, audit tables where display order carries meaning — line item sequence, step ordering, priority ranks — because the rows may have persisted in the wrong order without any error surfacing.

Debugging layout issues: publish the views, then read them. The rendered Blade is the actual source of truth for column behavior, and it's more informative than the README. Publish in a throwaway branch, read, and revert if you don't want the maintenance burden.

Extension point is the class, not config. There's no config file and no service provider of consequence. If you need behavior the package doesn't offer, subclass TableRepeater and override — that's the supported path. The published views are the second lever: absorb UI gaps by owning CSS, not by patching PHP in vendor/.

Rehearse the exit before you expand. Spend an hour on a branch swapping your wrapper back to stock Repeater and confirm the app runs. That hour de-risks the entire bet and tells you exactly what package-specific behavior you've accidentally grown dependent on. Do it before the package is used in twenty forms, not after.

Scope it to internal admin tooling. Filament forms are already a developer-facing surface; combining that with a single-maintainer presentation-layer dependency on a customer-facing flow is a mismatch. Line items in an internal order admin: good fit. A checkout form: no.