Map Multi Polygon Laravel Package

Technical Evaluation

Architecture fit. wm/map-multi-polygon is a Laravel Nova field package, not application domain logic. Architecturally it is a thin presentation layer: a Vue component rendered inside Nova's form/detail views that serialises a multi-polygon geometry into a resource attribute. That is a good fit only if (a) the organisation already runs Laravel Nova as its admin surface, and (b) the persistence layer can tolerate geometry as a JSON/GeoJSON text column or is fronted by a cast that converts to/from a spatial column type. If the target system needs polygons consumed by backend geospatial queries (PostGIS ST_Intersects, spatial indexing, area computation), this package delivers none of that — it is an editor, not a geometry engine. It should be evaluated as a UI accelerator with a data-contract you own.

Integration feasibility. Mechanically trivial: composer require wm/map-multi-polygon, register the field on a Nova resource, point it at a column. The real work is the data contract — what the field writes (raw GeoJSON MultiPolygon? an array of coordinate rings? WKT?), the coordinate reference system it assumes (almost certainly WGS84/EPSG:4326 as delivered by browser map libraries), and whether ring winding/closure is normalised. Each of those needs to be verified empirically, not assumed, because the package has no dependents and no external documentation trail to cross-check against.

Technical risk. Material, and concentrated in three places:

• Supply chain and bus factor. Zero stars, zero dependents, single-publisher (a web agency publishing under its own vendor namespace). The upstream repository is now confirmed as webmappsrl/map-multi-polygon. There is no community signal that the frontend component has been exercised against Nova's internals beyond the author's own deployments. Nova field packages are tightly coupled to Nova's private Vue/Inertia component API, which changes across major versions.
• Upgrade fragility. Nova 4 (Vue 2) to Nova 5 (Vue 3) is a breaking change for field components. A zero-adoption package is unlikely to be promptly patched for the next Nova major, which converts this from a dependency into a maintenance liability at your next platform upgrade.
• Map provider dependency. Rendering requires a tile source and possibly a drawing library plus API credentials. That introduces an external runtime dependency (availability, rate limits, key management, licensing terms for commercial tile usage) into what looks like an internal CRUD form.

Change since last assessment (v1.0.4, 2025-05-27). Patch release, single fix: "handle null value in fillModelWithData". No new features, no deprecations, no public API change, no declared breaking change — it does not alter the architectural verdict. Two things are worth extracting from it:

1. Upstream is alive, but only just. A patch commit in May 2025 confirms the maintainer is still shipping, which slightly softens (but does not remove) the abandonment concern. It is a single-commit patch — not evidence of a maintained test matrix or Nova-version support policy.
2. The fix lands squarely on the serialisation path we depend on. fillModelWithData is the hydrate-from-database path — the step that turns a stored attribute back into editor state. A null-handling defect there means records with a null or absent geometry were previously mishandled, which is precisely the round-trip correctness risk already flagged. Treat this as confirmation that the serialisation path is under-tested upstream rather than as a resolved issue, and extend the spike accordingly (see below).

Key questions to resolve before commitment.

1. Which Nova major/minor versions and Laravel/PHP constraints are declared in composer.json, and is that range actively tested?
2. What exact payload is written to the attribute — GeoJSON, WKT, or a provider-specific object? Is it stable across edits (round-trip fidelity)?
3. Does it preserve multi-polygon semantics (multiple exterior rings, interior holes/rings) or silently flatten to a single polygon?
4. Which map/tile provider and drawing library are bundled, and are API keys required? Are keys injected server-side or exposed in the client bundle?
5. Is there any validation (self-intersection, minimum vertices, ring closure, coordinate bounds), or does the field accept degenerate geometry that downstream consumers must sanitise?
6. What is the licence, and does it permit vendoring/forking?
7. Is there a test suite, and does it cover the serialisation path (the part you actually depend on)? Specifically: is there a regression test for the fillModelWithData null case fixed in v1.0.4, and does the changelog for v1.0.4 ship with one?
8. What was the observable symptom of the v1.0.4 null bug — blank editor, exception on form load, or silent data loss on save? It determines whether v1.0.3-and-earlier records may already contain corrupted geometry.

Integration Approach

Stack fit. Appropriate only for a Laravel + Nova estate on a currently supported Nova version. For anything else — Filament, Livewire, Inertia/React front ends, headless APIs — it is not reusable; you would take the underlying map component or build the editor directly.

Migration path. Two scenarios:

• Greenfield attribute. Add a json/text column (or PostGIS geometry(MultiPolygon, 4326) with an Eloquent cast), attach the field, done. Lowest effort, ~1–2 days including validation.
• Existing geometry store. If polygons already live in a spatial column or a bespoke format, you need an adapter layer: a Nova cast or accessor/mutator that translates the package's stored representation to and from your canonical format. Budget for this explicitly — it is the most likely place for silent data corruption on edit, and it must be covered by round-trip tests.

Compatibility. Verify against your pinned Nova version first, in a scratch branch, before any resource is wired up. Check the package's version constraint against your laravel/framework and php constraints; a narrow constraint may force a Composer conflict that decides the question for you. Baseline on v1.0.4 or later — there is no reason to test against a version with a known null-hydration defect.

Sequencing.

1. Spike (1–2 days). Install on a throwaway Nova resource, draw a polygon-with-hole, save, inspect the raw DB value, re-open, re-save, diff. Confirm round-trip fidelity and geometry semantics. Add null-path cases explicitly, given v1.0.4: a record created with no geometry at all, a record whose column is explicitly NULL, and a record whose column holds an empty array/null JSON. Then save each through the field. This single test de-risks most of the assessment and directly exercises the code path that was just patched.
2. Vendor decision. Given zero adoption, plan to fork into your own vendor namespace and pin an exact version, or accept a pinned upstream with no upgrade path. Do not treat upstream as maintained on your behalf. Fork from v1.0.4 so you inherit the null fix rather than re-fixing it.
3. Contract definition. Write down the storage format, SRID, and validation rules as an internal spec; implement server-side validation rules (custom Laravel rule) independent of the field's client-side behaviour, since a client-side map cannot be trusted as a validation boundary. Include the null/empty-geometry case in the spec — it is now a demonstrated edge case rather than a hypothetical.
4. Data audit (conditional). If you already run a pre-1.0.4 version anywhere, query for records where the geometry column is NULL or malformed and confirm they are genuinely empty rather than nulled by the bug.
5. Pilot on one resource with a small user group; instrument save failures and malformed-geometry rejections.
6. Generalise only after the pilot and only with the fork in place.

Operational Impact

Maintenance. Low ongoing cost if pinned and forked; potentially high and lumpy if consumed directly from upstream. v1.0.4 shows the maintainer is responsive enough to ship a one-line fix, which improves the near-term picture — but a two-year-old package receiving isolated single-commit patches is not the same as a maintained dependency with a support matrix. The realistic model remains: pin now, expect no upstream fix for the next Nova major, and own the Vue component yourself from that point. That is a small but non-zero permanent engineering commitment concentrated in one or two people — a knowledge-concentration risk worth naming.

Support. No SLA, no issue-tracker volume to infer responsiveness from, no dependents to lean on for community answers. Escalation path is a direct email to the publishing agency. The v1.0.4 patch is a mild positive signal on responsiveness; it does not constitute a support commitment. Acceptable for an internal admin tool; not acceptable for anything with a hard availability requirement.

Scaling. Two axes. Data volume: each edit ships the full geometry to the browser and back — fine for parcel/boundary-scale polygons, poor for thousands of vertices or hundreds of shapes per record. Query performance: JSON/text geometry cannot be spatially indexed; if downstream logic filters by location, plan the cast-to-PostGIS path and GiST index from the start rather than retrofitting. Also consider tile-provider rate limits if many editors use the map concurrently — self-hosted tiles remove that constraint at the cost of ops burden.

Failure modes.

• External tile provider outage or key expiry → editors blocked, no graceful degradation.
• Nova upgrade → field component fails to mount; form unsalvageable until patched by you.
• Malformed or degenerate geometry written by the client (self-intersecting rings, unclosed rings, dropped holes) → silent downstream failures in reporting or spatial queries; mitigate with a server-side geometry validation rule.
• Null/absent geometry mishandled on form load (the v1.0.4 defect class) → editor fails to mount or, worse, overwrites an existing value on save. This is now demonstrated rather than theoretical; regression-test it and hold the pin at v1.0.4+.
• Edit round-trip loss if the adapter between the package's format and your canonical format is not symmetric.
• Credential exposure if map keys are shipped in the client bundle.

Ramp-up. For a Laravel/Nova developer, hours — it is a field, not a subsystem. The real ramp-up is domain: GIS semantics (SRID, winding order, holes, multi-polygon vs polygon-collection) and the data contract your team must own. Non-technical editors will need brief UX guidance on drawing accuracy and how to correct a mis-drawn boundary, since geometric errors are invisible to them until a downstream report breaks. Overall: worth a short spike, worth pinning at v1.0.4 and forking, not worth adopting as an unexamined transitive dependency.