Filament Code Editor Laravel Package

Getting Started

This package is a Filament plugin, and v2.0.0's headline change is Filament v4 support. That single line carries more upgrade weight than it looks like: it aligns the package with Filament's own major version, which moved Forms/Infolists into Filament\Schemas, consolidated actions under Filament\Actions, and switched the frontend to Tailwind v4. Treat this as a major upgrade of your panel stack, not a patch.

First steps:

1. Confirm your panel's current Filament version before touching the package:

   composer show filament/filament | grep versions
   

2. Read the constraints, not the changelog. v2.0.0 is a major bump, so the honest question is whether it still supports Filament v3 ("filament/filament": "^3.0 || ^4.0") or dropped it ("^4.0" only). That determines whether this is a same-day upgrade or a scheduled migration.
3. Install/upgrade:

   composer require <vendor>/<package>:"^2.0" -W
   php artisan vendor:publish --tag="<package>-config"   # if the package ships config
   php artisan filament:upgrade                          # re-publish Filament assets/theme
   

4. Where to look first: the package's src/ service provider (to see how it hooks into panels) and its README install snippet. Filament plugins are almost always activated in a panel provider:

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

5. First use case: register the plugin on a single non-critical panel (e.g. a local/staging admin panel), load one resource that exercises the plugin's feature, and confirm rendering under Filament v4's new asset pipeline before rolling to production panels.

Implementation Patterns

Per-panel registration, not global. Filament plugins are opt-in per panel. Register explicitly in each PanelProvider and keep a short list of plugins in one place (a trait or config array) so adding a second panel doesn't silently lose the feature.

Version-lockstep in composer.json. Because the package version now tracks the Filament major, express that in constraints so a future composer update can't produce a mismatched pair:

"filament/filament": "^4.0",
"<vendor>/<package>": "^2.0"

Avoid "*" or loose "^1.0 || ^2.0" here — you want the mismatch to fail at install time, not at render time.

Upgrade in a branch with a Filament v4 baseline. Sequence: bump filament/filament to v4 → run php artisan filament:upgrade → move your own resources from Form to Schema (->form(Form::make()) → ->schema(Schema::make())), and Section/Grid imports from Filament\Schemas\Components\* → then upgrade this package. Doing the package bump first makes any breakage ambiguous between the two.

Custom theme must be rebuilt. Filament v4 is Tailwind v4 (CSS-first config). If you have a custom theme, your resources/css/filament/admin/theme.css needs @import 'tailwindcss' plus @source directives pointing at vendor views, then:

npm run build

Any class names this plugin emits that aren't in your @source globs will render unstyled — a classic "the plugin is broken" false alarm.

Test the plugin surface, not just the install. Filament is Livewire-first, so component tests give fast feedback:

Livewire::actingAs($admin)
    ->test(EditUser::class, ['record' => $user->id])
    ->assertFormSet(['name' => $user->name]);

Add a smoke test that boots each panel provider — that catches plugin registration regressions (missing ->plugin(), unregistered asset) that unit tests miss.

CI matrix. Pin filament/filament to ^4.0 in CI. If the package supports both v3 and v4, add a second matrix leg — otherwise you'll only ever learn about v4 breakage in production.

Gotchas and Tips

• The major bump is the breaking change. v2.0.0 almost certainly drops Filament v3 (or changes its API surface to match v4). An app on Filament v3 cannot take this update. Verify with composer why-not <vendor>/<package> 2.0 when the resolve fails — it names the conflicting constraint directly.
• Transitive conflicts are the most likely failure. Another Filament plugin still pinning filament/filament: ^3.0 will block v4 entirely. composer update -W surfaces these; resolve them all in one pass rather than package-by-package.
• Namespace moves break published stubs. If you published views or generated classes from the v1 package, they may reference Filament\Forms\Components\Section, Filament\Forms\Form, or old action classes. Re-publish and diff rather than editing by hand:

  php artisan vendor:publish --tag="<package>-views" --force
  

• Clear aggressively after upgrading. Filament caches panel/component registration. Symptoms of a stale cache: plugin appears on one panel but not another, or old markup persists.

  php artisan optimize:clear && php artisan filament:optimize-clear && php artisan view:clear
  

• Re-run php artisan filament:upgrade whenever you bump either Filament or the plugin — v4 ships new public assets, and a stale public/css/filament produces subtly broken styling that looks like a plugin bug.
• Check PHP and Livewire floors. Filament v4 requires PHP 8.2+ and Livewire v3. If your app is on Livewire v2, the package upgrade will cascade into a Livewire migration — plan for it.
• Debugging checklist order: (1) php artisan about for versions, (2) composer show <vendor>/<package> to confirm v2 is actually installed, (3) confirm ->plugin() is in the right panel provider, (4) rebuild the theme, (5) clear caches. Most "v4 broke the plugin" reports resolve at step 3 or 4.
• Extension point to prefer: if you need to alter the plugin's output, use its published views/config or documented hooks rather than subclassing internals. v2.0.0 is a fresh major, so internal classes are the least stable surface right now.
• Report issues with versions attached. With a v3/v4 split in the wild, a bug report without composer show output and the Filament version is often unfixable — include both, plus the panel provider snippet.