Laravel Filament Rich Editor Source Ai Laravel Package

Getting Started

This release (1.0.4) is a compatibility release, not a feature release. Its only job is to widen the package's constraints so it installs cleanly alongside Filament 5.x and Livewire 4.x. Treat it as your green light to upgrade an existing panel rather than as something to evaluate on its own merits.

Minimal path:

1. composer require <vendor>/<package>:^1.0.4 — check the resolved graph with composer why filament/filament and composer why livewire/livewire before you run anything else. On a fresh install this is a no-op; on an upgrade it's where the work is.
2. Register the plugin in your panel provider:

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

3. Publish what's publishable once: php artisan vendor:publish --tag=<package>-config (and -views / -assets if offered), then php artisan filament:assets.
4. Load a page that actually uses the plugin — not the dashboard. The dashboard renders even when a plugin's assets or Livewire component registration is broken.

Where to look first:

• composer.json of the package — confirm the filament/filament and livewire/livewire constraints genuinely include ^5.0 / ^4.0 and not just >=4.0 hand-waving.
• src/*Plugin.php — the register() / boot() methods tell you what it injects into the panel (assets, render hooks, routes, navigation).
• CHANGELOG.md / the 1.0.4 diff — a compatibility bump with no other changes means the surface API is stable; you should not need to touch your own code.

First use case: drop it into one panel of a multi-panel app and confirm navigation, assets, and any Livewire-driven interaction all behave before rolling it across the rest.

Implementation Patterns

Pin the whole trio together. Filament, Livewire, and this package move as a unit. Lock filament/filament:^5.0, livewire/livewire:^4.0, and this package ^1.0.4 in composer.json rather than letting the resolver pick. Compatibility releases like this one exist precisely because the constraint graph is brittle; make the intent explicit so the next composer update can't quietly downgrade you into an unsupported pair.

Upgrade in a branch with the test suite as the gate. The 1.0.4 change is low-risk by construction, but Livewire 4 is where behavioural drift hides. Run your existing Filament/Livewire feature tests first — untouched — and only then start poking at the UI. If tests pass and the UI is odd, you're looking at an asset problem, not a code problem.

Multi-panel registration. Register the plugin only on the panels that need it. If several panels share it, extract the registration into a small helper or a base panel provider so the plugin's config keys stay consistent across panels — divergent config per panel is a common source of "works in admin, broken in app" bugs.

Config-driven behaviour, not code edits. Anything the package exposes in config/<package>.php should be set via env-backed config values so staging and production can differ without a deploy of divergent code. Publish the config, then edit the published copy — never the vendor file.

Keep custom Livewire components on the same conventions as the package. If you've extended or wrapped the plugin's components, mirror the patterns the package itself now uses under Livewire 4 (computed properties over public property sprawl, explicit wire: keying in loops, no reliance on removed lifecycle hooks). Divergence here is what turns the next compatibility bump into a rewrite.

Test with the framework's helpers. Livewire::test() for component behaviour, Filament's panel/table/form test helpers for resource-level assertions. A compatibility bump is the moment to make sure you have at least one test that touches the plugin's primary interaction — otherwise you have no signal at all next time.

Gotchas and Tips

• Stale published assets are the #1 post-upgrade symptom. After bumping, run php artisan filament:assets, republish any -assets tag, and clear compiled views. A plugin that "doesn't work" after a version bump is usually serving the old bundle.
• composer update may not move you. If another dependency still caps Livewire at 3.x, composer will happily keep you on the old package version with a silent non-upgrade. Verify with composer show <vendor>/<package> that you actually got 1.0.4, not just that the command exited 0.
• Config cache in production. php artisan config:cache will lock in whatever the config said at build time. After changing plugin config, re-run config:cache (or optimize:clear) as part of deploy — a config change that "didn't take" is almost always this.
• Plugin ordering matters. If the plugin registers render hooks or navigation alongside other Filament plugins, order in ->plugins([...]) can change output. If something renders twice or not at all, reorder before you debug deeper.
• Livewire 4 breakage shows up in your code, not the package's. The package now supports Livewire 4; your custom components, Alpine snippets, and any wire: bindings in overridden views may not. Audit overridden views after the upgrade — they are the least-tested surface you own.
• Debugging order that actually works: php artisan about (confirm versions), check the browser console and network tab for 404s on assets (confirms stale publishing), then Livewire devtools for component hydration errors, then application logs. Jumping straight to logs wastes time on asset problems.
• Extension points: prefer subclassing the plugin class or overriding views via vendor:publish --tag=<package>-views over editing vendor files. Published views are yours to break and yours to maintain — note them in your upgrade checklist so the next compatibility release reminds you to diff them against the new upstream versions.
• Vendor constraints are a promise, not a guarantee. A ^5.0 constraint means the package declares support. Smoke-test the specific Filament features you rely on (tables, forms, actions, notifications) rather than assuming blanket compatibility.