- How do I show a Filament RepeatableEntry as a table instead of a stacked list?
- This package renders Filament's RepeatableEntry as a table, so repeatable or related values display as aligned columns and rows rather than stacked key-value blocks. You swap the standard entry for the package's table variant inside your resource infolist or schema. Check the README for the exact class and method names in the version you install, since the public API can shift between majors.
- How do I install icetalker/filament-table-repeatable-entry with Composer?
- Install it with composer require icetalker/filament-table-repeatable-entry, then read the README section for your tagged version to see whether any plugin registration or publishing step applies. Only run vendor:publish for the tags the documentation lists, and diff the output before ever using --force, because that flag overwrites local customisations. Commit composer.lock afterwards so the resolved Filament version stays pinned across machines and CI.
- Does filament-table-repeatable-entry support Filament v5?
- Version 2.1.0 is a dependency-compatibility release pointed at Filament v5, so it is the version to reach for on a v5 admin panel. The decisive question is whether that release replaces Filament v4 support or allows both, which you can settle by reading the require block in the package's composer.json for your exact tag. If the floor moved to v5 only, adopting this package silently drives a larger platform upgrade; if the constraint is dual-compatible, the risk drops sharply.
- What Laravel and PHP versions does this package require?
- The authoritative answer is the require block in composer.json for the specific tag you install, because a Filament major bump usually raises minimum PHP and Laravel constraints at the same time. Run composer why-not icetalker/filament-table-repeatable-entry to see exactly which of your pinned constraints are blocking resolution. Write the resulting package version by Filament version by Laravel version by PHP version matrix into your repo so the next upgrade does not have to re-derive it.
- Do I need to register a plugin or publish assets for this package?
- It depends on the release: some Filament companion packages register a panel plugin, others are pure component or view swaps, and some publish Blade views or config you can override. After installing, read the README section for your version and publish only the tags it documents. If you have edited any published file, diff before re-publishing with --force so you do not lose those changes.
- Can users add and edit repeatable rows inline in a Filament table without opening a form?
- That is the package's core purpose: it brings repeater-style editing to table rows so users can add and manage multiple entries per record without leaving the table for a separate form. It is aimed at repeatable values such as line items, notes, contacts or key-value pairs shown in an admin listing. It assumes a Laravel application with a Filament-backed panel and provides nothing outside that stack.
- What kinds of data work well with a table repeatable entry?
- Anything naturally repeatable per record: order line items, notes, contacts, addresses or arbitrary key-value pairs. Because the output is tabular, it works best when each entry has a small, consistent set of fields that fit cleanly as columns. Very wide or deeply nested entries are usually better served by a full Repeater inside a dedicated form page.
- How should I test a Filament integration package like this in CI?
- A meaningful matrix runs the package against each supported Filament major on its matching Laravel and PHP versions, because constraint collisions surface at install time rather than at runtime. Unit tests alone will not catch what matters here: Filament majors shift Blade and Livewire patterns plus asset registration, so a broken admin UI can still leave a green suite. Add at least one browser or Dusk smoke test that renders a panel page using the table before you depend on it.
- Is this package safe to use in production?
- It is a thin integration layer over Filament, so the risk profile is dominated by dependency constraints rather than its own domain logic. The two hazards worth planning for are an unresolvable dependency graph against a pinned Filament version, and silent UI regressions after a Filament major bump, since compatibility releases are often validated for boot rather than for every screen. Smoke-test each panel page that uses it after any upgrade and keep the package a follower of the framework upgrade, never a driver.
- What is the alternative to adding a package just to render repeatable entries as a table?
- You can get much of the same result with Filament's own schema and view components plus a custom Blade view, which removes the third-party dependency but adds maintenance work you own. The package earns its place when you want that behaviour without writing and maintaining the view yourself. Weigh that against single-maintainer risk: a package that tracks Filament majors is only worth depending on if it keeps tracking them on a reasonable cadence.