Filament Table Repeatable Entry Laravel Package

Getting Started

This release is a compatibility bump: the package now supports Filament v5. If you are starting fresh, treat it as a Filament plugin first and a Laravel package second — almost all of your day-to-day work will happen in a panel provider, not in config/.

1. Install alongside a v5 panel.

   composer require <vendor>/<package>:^2.1
   php artisan vendor:publish --tag="<package>-config"   # check the README for exact tags
   php artisan migrate
   

   Confirm composer.json resolves filament/filament:^5.0 — if you are still on v4, pin the package to the previous minor rather than forcing the constraint.

2. Register the plugin in your panel provider. This is the single integration point for most Filament plugins:

   public function panel(Panel $panel): Panel
   {
       return $panel
           ->plugin(<Package>::make());
   }
   

3. Look here first, in order: README.md (registration snippet and any required ->plugin() arguments), CHANGELOG.md (v2.1.0 is a narrow release — scan v2.0.0 for the real upgrade notes), src/*ServiceProvider.php (what is published and what is auto-loaded), and config/<package>.php (the knobs you will actually touch).

4. First use case: register the plugin on a single non-production panel, load the page or resource it adds, and confirm navigation and authorization behave as expected before wiring it into the main admin panel. Filament plugin bugs usually surface as a missing nav item or a 403, not as an exception, so verify visually rather than trusting a green test suite.

Implementation Patterns

Register per panel, not globally. Filament plugins are attached to Panel instances. If you have separate AdminPanelProvider and AppPanelProvider, register deliberately — most teams want admin-only, and a plugin that registers resources into every panel will leak navigation into user-facing areas.

Keep the package version and Filament version in lockstep. Because v2.1.0 exists specifically to support Filament v5, treat the pair as a unit. In CI, assert the resolved versions rather than assuming:

composer show filament/filament <vendor>/<package> | grep -E '^(name|versions)'

Centralize panel configuration. Wrap plugin registration plus its config in a small helper or a dedicated Panel config class so the ->plugin() call, any ->navigationGroup(), and authorization callbacks live in one place. Filament panel providers grow fast, and plugin arguments scattered across providers are the usual cause of "works locally, missing in staging."

Customize via published views/config, not by forking. Publish the config and any views, then commit them. Overriding a vendor Blade view through render hooks is more upgrade-durable than subclassing the plugin's pages, which couples you to internal method signatures that can move between Filament majors.

Test through Filament's helpers. Use Livewire::test() against the plugin's pages/resources and Filament's assertion helpers for table and form state. A plugin upgrade is exactly the moment to have those tests in place — they catch the v4→v5 behavior shifts that the release notes will not mention.

Upgrade in a dedicated branch. Bump filament/filament and this package together, run php artisan filament:upgrade (or the v5 equivalent), rebuild assets, then run the suite. Do not mix this with feature work.

Gotchas and Tips

• "Support Filament v5" is the entire changelog entry. That is a signal, not documentation. Assume the underlying v4→v5 migration guide applies to you too — read Filament's own upgrade notes, since plugin-level compatibility does not guarantee your custom pages, widgets, or theme compile cleanly.
• Version constraints may be exclusive. Many packages ship a v2.x line for Filament v4 and a separate line for v5. Check whether ^2.1 allows both; if it does, fine, but if the package dropped v4 support in this release, your downgrade path is a version pin, not a config flag.
• Stale caches mask everything. After upgrading, run php artisan optimize:clear and rebuild frontend assets. A surprising share of "the plugin broke" reports are cached compiled views or an un-rebuilt Filament asset bundle.
• Publish tag collisions. Re-running vendor:publish after an upgrade can silently overwrite your customized config or views. Use --force consciously, and diff before committing.
• Multi-panel leakage. If navigation items or resources appear in a panel where you did not register the plugin, another provider is calling ->plugin() — grep the codebase rather than debugging the package.
• Authorization defaults. Policies and canViewAny/canAccess behavior often change between majors. Re-verify with a non-super-admin user; super-admin bypasses hide these regressions completely.
• Extension points worth knowing: the published config file, Filament render hooks (for injecting markup without touching vendor views), custom themes via ->viteTheme(), and the plugin's make()/->plugin() arguments for navigation and authorization. Prefer these over subclassing.
• Debugging aids: php artisan about for the resolved Filament version, php artisan filament:optimize / optimize:clear for cache issues, and the browser console for asset 404s after an upgrade.
• Pin exact versions in composer.lock and deploy from it. Given how thin the release notes are, reproducibility across environments is your main safety net.