Resizable Modal Laravel Package

Getting Started

This is a single-purpose Filament plugin: it attaches drag-to-resize handles to action modals so users can widen/narrow modals that would otherwise be locked to maxWidth(). With 8 stars and no dependents, treat it as a small utility rather than infrastructure — verify the internals before betting a critical admin flow on it.

Install and register (the whole setup):

composer require anish/resizable-modal

// app/Providers/Filament/AdminPanelProvider.php
use Anish\ResizableModal\ResizableModalPlugin;

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

Then clear caches (php artisan filament:optimize-clear or php artisan optimize:clear) — Filament asset registration is cached, and a missing handle is almost always a stale cache, not a bug.

Where to look first:

1. The plugin's service provider — it will show what assets are registered (FilamentAsset::register([...])) and whether there's a publishable config.
2. The shipped JS file in resources/dist/ — this is where the actual resize logic lives, and it tells you which DOM selector it hooks into (typically .fi-modal-window or similar).
3. The README's screenshots/demo video (linked in the repo) — faster than reading code to understand the intended UX.

First use case: a "View" or "Edit" action modal that renders a wide table, an infolist with many columns, or a side-by-side form. Instead of guessing a ->modalWidth('7xl') and hoping it fits every viewport, you let the user drag the modal to the width they actually want.

Implementation Patterns

Global enable via panel plugin. The simplest pattern is registering the plugin once in the panel provider, which makes every action modal resizable. Good for internal admin panels where users are power users.

Scope by modal content, not by modal. Since the plugin typically hooks all modals, the practical pattern is: keep default modals narrow (delete confirmations, simple confirmations) and give resizable modals to actions that genuinely need it. If the plugin doesn't offer per-action opt-out, you can usually gate with CSS:

->extraAttributes(['class' => 'resizable-modal'], true) // on the action

…and scope the resize handles' visibility in your own CSS if the package exposes a class hook. Check the shipped CSS before doing this; if handles are injected by JS on open, this won't be enough and you'll need to conditionally register the plugin per panel instead.

Pair with modalWidth() as the starting size, not the final size. Set a sensible ->modalWidth('3xl') on the action so the modal opens at a usable size and the user resizes from there. Without a baseline, users on small screens start cramped and have to drag every time.

Separate panels for separate audiences. This is the cleanest scoping trick with a package this small: register the resizable plugin only on your internal/staff panel (AdminPanelProvider), not on a customer-facing panel. Two panels, two PanelProviders, one line of difference.

Custom Livewire modals. If you're rendering your own <x-filament::modal>, the plugin's JS may or may not attach — it normally targets Filament action modals. Test in isolation before assuming it works for blade-driven modals.

Combine with action modals inside tables and forms. It works the same for Tables\Actions\ViewAction, EditAction, and custom Action::make()->form(...). Verify with at least one table header action and one row action, since Filament mounts these differently.

Test the resize persists across actions. Opening action A, resizing, closing, opening action B — check whether the size is remembered or reset. If remembered, that's usually desirable and worth documenting for your team. If reset, that's fine too, but know which you're shipping.

Gotchas and Tips

Stale assets after composer require. Filament caches the asset manifest. If you install and see no handles, it's php artisan filament:assets / php artisan optimize:clear before you go debugging JS.

Livewire morphing can strip the handle DOM. Filament modals re-render on validation errors, form state changes, and nested actions. If the package injects DOM on modal-open, a morph can wipe it. Repro: open a resizable modal, submit the form with a validation error, then try to drag. If handles vanish, that's a bug in the package and you should file it — but knowing the repro saves an afternoon.

maxWidth() fights the resize. If you've set ->modalWidth('5xl'), Filament's utility class may cap the resized width, or the JS may override it and cause a layout shift on next open. Test with a deliberately wide drag (past your viewport) and confirm behavior is sane rather than a horizontal-scroll blowout.

Touch and small screens. Drag handles are mouse-oriented. On a tablet, the handle may be hard to grab or may conflict with modal scroll. If your admin team uses iPads, test on a real device — this is the most likely place a package like this fails silently.

Dark mode and theming. The handle's styling may be hardcoded. Check it renders visibly against your Filament theme, especially if you use a custom ->colors() palette or a light/dark toggle.

Version pinning. The package targets Filament v4/v5 and was last released mid-2026. Filament v5 moves fast; pin the package in composer.json and re-verify after every Filament minor upgrade. With 8 stars and 0 dependents, there's no crowd to surface a regression for you — you are the QA.

CSP and Vite. If your panel is behind a strict Content-Security-Policy, inline style manipulation from the resize JS (setting style.width on drag) is usually fine, but inline <style> injection may be blocked. Verify on your production CSP, not just locally.

No API surface = no extension points. Don't plan to subclass or override this plugin. If you need conditional behavior (per-action, per-role), the practical route is registering the plugin on a separate panel, or wrapping it in your own small plugin that conditionally delegates. Budget for that rather than assuming a config file exists — check for config/resizable-modal.php first.

Fallback plan. Because the plugin is tiny, if it breaks on a Filament upgrade you can replace it with ~30 lines of JS hooking the modal's open event. Keep that in mind as insurance: the value here is convenience, not irreplaceable logic. Don't let it become load-bearing.