Filament Leaflet Map Laravel Package

Technical Evaluation

Architecture fit

• m2collective/filament-leaflet-map is a Filament plugin that wraps the Leaflet JS mapping library. Architecturally it is a thin PHP shell (a form field and/or dashboard widget) plus front-end assets registered through Filament's asset pipeline, with the actual rendering handled client-side.
• This is a good fit where the map is a presentation and data-entry concern inside an admin panel: store/asset locations, delivery zones, service catchments, territory assignment, site selection by lat/lng. It is not a GIS platform and should not be evaluated as one.
• It sits alongside the existing Laravel/Filament stack with no new persistence layer of its own — coordinates live in your own columns, which keeps the data model portable.

Integration feasibility

• Low integration cost: composer require, plugin registration in the PanelProvider, and a component added to a resource form or widget. Expect roughly a day of spike work for a developer already fluent in Filament.
• Real dependencies to verify rather than assume: supported Filament major version (v3 vs v4), PHP floor, and whether Leaflet assets are bundled/published or pulled from a CDN. The CDN case is the one that bites — CSP headers, air-gapped environments, and offline dev all break on it.
• The release itself gives us almost nothing to assess: version 0.1.0 with no changelog entries beyond a compare link. Treat everything above as inference from the package name and Filament plugin conventions, not confirmed capability.

Technical risk

• Pre-1.0 maturity. 0.1.0 is the first published cut. No semver stability guarantee, no documented deprecation policy, no evidence of production usage. Pin the exact version and read every diff.
• Bus factor. A single-org package with no visible release notes suggests limited maintenance bandwidth. Absence of a changelog is itself a signal about release discipline.
• Livewire lifecycle. Leaflet initialized in a Livewire component is a well-known failure mode — DOM morphing on re-render can orphan or duplicate the map instance. This is the single most likely source of "works in the spike, breaks in the app" bugs.
• Third-party tile dependency. Tiles are served by an external provider. OSM's tile usage policy prohibits heavy production use; commercial providers impose keys, quotas, and billing. This is a procurement and cost decision, not just a technical one.
• Attribution/licensing. OSM-derived tiles require visible attribution. Getting this wrong is a compliance issue, not a cosmetic one.

Key questions

1. Which Filament major version(s) are supported, and what is the PHP floor?
2. Are Leaflet JS/CSS bundled and publishable, or CDN-loaded? Does it work behind a strict CSP and in an air-gapped environment?
3. What component types ship — form field, infolist entry, dashboard widget, table column? Can a map be read-only as well as interactive?
4. Is there a configurable tile provider/URL, or is it hardcoded?
5. Does it support marker clustering, search/geocoding, drawing tools, or is it display-and-click only?
6. Is the map state correctly re-initialized across Livewire re-renders and modal opens?
7. What is the maintainer's release cadence, and is there a tagged changelog or only commit comparisons?
8. Any test suite, CI, or static analysis visible in the repo?

Integration Approach

Stack fit

• Assumes Laravel + Filament + Livewire + Alpine. The PHP surface is trivial; the risk concentrates in JS asset loading and Livewire interaction. Teams without front-end depth should expect to lean on a developer comfortable with Leaflet.
• No database migrations or schema opinions — coordinates are yours to model. Favorable for later portability.

Migration path

• Greenfield adoption: no incumbent to migrate from. If replacing a hand-rolled Leaflet/Alpine implementation, do a feature-parity checklist first; if replacing a paid GIS/embed product, confirm the plugin covers your interaction needs before committing.
• Exit cost is low precisely because the package is a thin wrapper — you can vendor or fork the field component without rewriting your data model.

Compatibility

• Pin the exact version in composer.json (0.1.0, not ^0.1) until a tagged changelog exists.
• Validate against the Filament version already in production. Filament majors have historically shipped breaking asset and component-API changes; an early-stage plugin is unlikely to span them.
• Confirm tile provider terms before the pilot, not after — the provider decision shapes config and cost, and rework there is annoying.

Sequencing

1. Spike (1–2 days). Install in a throwaway panel. Confirm asset loading under your CSP, and confirm the map survives a Livewire re-render and a modal open/close.
2. Narrow production slice. One form field on one internal resource with a small user group. Instrument tile request volume.
3. Tile provider decision. Move off public OSM tiles to a commercial or self-hosted provider with a key, quota, and billing owner assigned.
4. Read-only rollout. Dashboard widgets / infolists once interactivity is proven stable.
5. Broaden. Only after two clean minor upgrades.

Operational Impact

Maintenance

• Budget recurring review time per release — expect breaking changes at 0.x and treat each bump as a mini-migration. Roughly 1–2 hours per release for triage, more if the field API shifts.
• Write a thin internal wrapper around the component so a future swap (fork, alternative plugin, in-house field) touches one file. At this maturity, that abstraction is cheap insurance rather than over-engineering.

Support

• Open-source, community-supported, no SLA. No vendor to escalate to. Internal ownership must be explicitly assigned — name a person, not a team.
• The empty release notes mean your team becomes the de facto changelog. Diffs are the documentation.

Scaling

• Application scaling is a non-issue (client-side rendering). The scaling constraint is the tile provider: request volume grows with user count and map pan/zoom activity, not with your infrastructure.
• Public OSM tiles are unsuitable beyond light internal use under their usage policy. Plan a commercial tier (with per-request pricing) or self-hosted tiles if usage is heavy or data must not leave your network.
• Geocoding, if used, is a separate quota and a separate vendor decision.

Failure modes

• Tile provider outage, rate-limit, or IP block → blank grey map with no error surfaced to the user. Requires monitoring and a user-facing fallback message.
• CSP or asset-publish misconfiguration → map fails silently on deploy. Add a smoke test on the map page.
• Livewire re-render → duplicated or frozen map, stale marker positions. Most likely bug class; test explicitly.
• Upgrade to a new Filament major → plugin breakage with no upstream fix timeline. Mitigation: the wrapper layer above.
• Credential exposure if geocoding/tile API keys are injected client-side — confirm the key model before shipping.

Ramp-up

• A Filament-fluent developer is productive in about a day. Leaflet-specific work (custom markers, clustering, drawing) is separate JS knowledge and should not be assumed present.
• Given 0.1.0 and the absence of release documentation, gate adoption to internal, non-customer-facing panels until at least one subsequent tagged release demonstrates maintenance activity.