Filament Popup Laravel Package

Technical Evaluation

Architecture fit. zpmlabs/filament-popup is a Filament panel plugin, so its value is gated on one architectural precondition: the application already runs a Filament admin panel (TALL stack — Laravel, Livewire, Alpine, Tailwind). It is not a general-purpose Laravel popup library. Expect the standard Filament plugin contract — a Plugin class registered on a PanelProvider, a service provider for config/migrations/views, and likely a Filament Resource for authoring popups plus a Blade/Livewire renderer for delivery. That is a clean fit if Filament is already the control plane for content operations; it is a poor fit if popups need to render on a public marketing site that is not Livewire-rendered, or if the team manages content outside Filament.

Integration feasibility. Mechanically low-effort: composer require, register the plugin in the panel provider, publish and run migrations, publish config/assets. The real feasibility question is not installation but delivery surface — where the popup is actually shown, under what targeting/trigger rules, and whether that renderer is coupled to Filament's authenticated panel context or usable on public routes. Confirm this in a one-day spike before committing.

Technical risk. High relative to the integration effort, driven by adoption signals rather than code quality:

The dominant risk is Filament major-version coupling. Filament iterates quickly and has historically shipped breaking changes across majors (v3 → v4 class/API moves). A small plugin with one maintainer and zero dependents will lag those upgrades. Secondary risks: single-maintainer bus factor, thin test coverage, and asset-pipeline assumptions (Vite vs. published assets) that may not match our build.

Key questions.

1. Which Filament and Laravel/PHP versions are supported in composer.json, and how wide is the constraint?
2. Does the renderer work outside an authenticated Filament panel (public pages, guest users), or is it panel-scoped only?
3. What targeting primitives exist — schedule, audience, page/route, frequency capping, dismissal persistence — and are they stored in our DB or vendor tables?
4. Are migrations publish-only (we own the schema) or vendor-owned?
5. Is there a test suite and CI? What is the issue-response history?
6. Does it ship compiled assets, or does it require our Vite build to include vendor JS/CSS?

Integration Approach

Stack fit. Requires Laravel + Filament; assumes Livewire for interactivity and Tailwind for styling. If our front end is Inertia/React or a separate SPA, the admin authoring side may still be useful but the delivery side likely is not — that split is the deciding factor.

Migration path. Treat this as an additive, reversible layer:

1. Spike on a branch: install, register plugin, publish config/migrations, run against a scratch DB.
2. Audit the published migration for table naming collisions and FK assumptions.
3. Confirm rendering on the intended surface(s) — panel-only first, public routes second.
4. Wrap the render call behind our own Blade component or view composer so the vendor API appears in exactly one place.
5. Pin the exact version in composer.json (no caret range) and record the fork point.

Compatibility. Verify the version matrix explicitly before scheduling work — Filament major, Laravel major, PHP minor, and Node/Vite for assets. Because there are zero dependents, we should assume we are the first integration at our specific version combination and budget for a patch or two. If a mismatch exists, the mitigation is a fork under our org with a maintained constraint, not a wait-and-see.

Sequencing. (a) Compatibility spike → (b) authoring-only rollout in a non-production panel to validate content-editor UX → (c) delivery on a low-traffic page behind a feature flag → (d) broaden surface area and targeting rules → (e) revisit build-vs-fork at the next Filament major. Do not sequence delivery before the renderer-scope question is answered; it changes the effort by an order of magnitude.

Operational Impact

Maintenance. Small-vendor dependency with a single maintainer. Budget an explicit owner and a periodic upgrade review tied to Filament releases, not a calendar. The MIT license and small surface area make an internal fork viable — estimate the plugin's core (resource CRUD, a renderer, a couple of models) as days, not weeks, to reimplement if abandoned. That ceiling is the main reason this is a tolerable bet despite the adoption numbers.

Support. GitHub issues only; no SLA, no vendor escalation. Internal SLAs must be written against our fork, not upstream. Content-editor questions ("why isn't my popup showing?") will land on our team, so targeting-rule semantics need documenting from the source.

Scaling. Authoring load is negligible. Delivery load depends entirely on implementation: if popup selection runs a DB query per request without caching, it becomes a per-page-view cost on high-traffic public routes. Push for a cached, pre-resolved popup set keyed by route/audience and invalidated on publish. Frequency capping and dismissal state will add per-user writes — confirm the storage strategy before enabling on public traffic.

Failure modes.

• Filament major upgrade → plugin breaks, admin panel fails to boot. Mitigation: pinned version, staging-first upgrades, fork on standby.
• Renderer exception on public pages → user-facing 500s. Mitigation: wrap the render in a try/catch and degrade to no-popup.
• Migration collision or vendor-owned schema → blocked deploys. Mitigation: publish and own migrations; review before merge.
• Asset build mismatch → unstyled or non-functional popups in production only. Mitigation: verify the production build, not just dev.
• Targeting misconfiguration → popup shown to the wrong audience (compliance/brand exposure). Mitigation: preview mode and a kill switch in config.

Ramp-up. Low for engineers already fluent in Filament — hours to productive, a day to confident. The steeper curve is on the content/ops side: authors need guidance on targeting semantics, scheduling, and dismissal behavior, and someone must own the "why isn't it showing" triage path. Net: cheap to try, cheap to exit, but only worth adopting if Filament is already the content control plane and the delivery surface is Livewire-compatible.