Map Multi Linestring Laravel Package

Technical Evaluation

Architecture fit. This is a Laravel Nova custom field whose purpose is to capture and persist GeoJSON MultiLineString geometries (routes, corridors, pipelines, service paths) through an interactive map editor inside the Nova admin. Architecturally it slots into the standard Nova field contract: a PHP Field subclass on the backend plus a compiled Vue component registered as a custom field asset. It is only appropriate if (a) Nova is already our admin layer, and (b) the domain genuinely needs multi-segment line geometries rather than a single polyline or a simple lat/lng pair. If either condition fails, this package is the wrong tool regardless of quality. The v1.0.4 fix confirms the field participates in Nova's attribute-comparison lifecycle (oldAttribute vs. new value) — i.e., it is a first-class field, not a read-only display widget, and it interacts with Nova's dirty-state and dependent-field machinery.

Integration feasibility. Composer-installable and namespaced under wm/, so adoption is a one-line dependency plus a Nova resource field declaration. The realistic friction points are: Nova major-version compatibility (Nova 4 vs. 5 asset pipelines differ materially), whether the field ships pre-built assets or requires npm run build in the host app, and the storage contract (JSON/geometry column vs. text). With 0 stars and 0 dependents there is still no community evidence that any of this works outside the author's own Nova install, so integration must be treated as an unverified spike, not a drop-in. The 1.0.x line now has at least four patch releases (1.0.0 → 1.0.4), which is a mild positive signal on cadence but does not substitute for downstream validation.

Technical risk. Still the dominant concern. Single-maintainer, zero-adoption artifact: no dependents means no downstream validation, no issue history to mine, and no signal on test coverage or CI. Bus factor is effectively 1. The 1.0.4 fix is a genuinely useful correctness patch — a null oldAttribute (the create/new-record case) previously threw during geometry comparison — but the fact that it shipped four patches into a 1.0 line suggests the field's edge cases are being found in production rather than by a test suite. For a field that renders third-party map tiles and parses user-supplied GeoJSON in the browser, the security and correctness blast radius remains non-trivial: XSS surface in the editor, malformed geometry handling, and hard dependency on whichever tile/JS mapping library is bundled (Leaflet/Mapbox/Google) with its own API keys, licensing, and rate limits.

Key questions.

• Which Nova versions are declared in composer.json, and are assets pre-compiled or source-only?
• What is the persistence format — raw GeoJSON in a JSON column, WKT, or a custom cast — and does it round-trip cleanly?
• Which mapping library and tile provider are bundled, and does it require our own API key?
• Is there server-side validation of geometry (closed rings, coordinate bounds, SRID) or is it client-trusted?
• Are there tests, a CI badge, a LICENSE, and a documented upgrade path? Specifically: is there a regression test covering the null-oldAttribute comparison fixed in 1.0.4?
• Does the comparison override behave correctly for dependent/dependsOn fields and for onlyOnForms()/read-only rendering, now that it is known to hook Nova's attribute diffing?
• Does the field degrade gracefully when the map fails to load?
• Who is the maintainer, and is there a stated support commitment or a fork we could own?

Integration Approach

Stack fit. Assumes Laravel + Nova + a JSON-capable database column. It is a good fit only where Nova is the system of record for the geometry and the editing workflow is occasional/back-office. It is a poor fit for high-volume geometry ingestion, public-facing map rendering, or any pipeline where geometries arrive from GIS tooling — those belong in PostGIS with a proper spatial layer, with this field as an optional manual-correction UI.

Migration path. Add the column as nullable JSON (or geometry if PostGIS is in play) so existing rows are unaffected — the 1.0.4 fix means a null geometry on record creation now round-trips without erroring, which makes the nullable-column rollout safe on this version (and unsafe on ≤1.0.3). Backfill only if there is a legacy representation to convert; otherwise treat the field as net-new and keep it non-required during rollout. Because there is no prior version of our usage, the migration is from whatever bespoke lat/lng or text field we currently use, and that conversion should be reversible until the spike passes.

Compatibility. Pin the exact version — composer require wm/map-multi-linestring:1.0.4 — rather than a caret range. With a thin release history, a ^ constraint buys nothing and forfeits reproducibility, and it would silently withhold or accept patches whose behavior we have not reviewed. Explicitly do not land on ≤1.0.3: the null-oldAttribute defect means creating a record with an empty geometry can error in the Nova form. Verify against our pinned Nova major and PHP version first; if assets are source-only, confirm our build toolchain (Vite vs. Mix, Node version) can compile the component, since Nova custom fields frequently assume a specific bundler generation.

Sequencing.

1. Spike (1–2 days). Install 1.0.4 into a scratch branch, wire one Nova resource, and test three paths: create with no geometry (the 1.0.4 regression case), edit-and-save an existing MultiLineString, and reload. Confirm dirty-state behaves (no perpetual "unsaved changes" prompt).
2. Vendor review. Read the field class and Vue component end-to-end; record tile provider, dependencies, asset build steps, and the oldAttribute comparison logic.
3. Fork decision. If the spike passes but maintenance looks thin, vendor the package into our monorepo under an internal namespace so we control patching — this is likely the correct end state given 0 dependents.
4. Harden. Add feature tests for the round-trip and for the null/empty-geometry create path (so a future upstream bump cannot reintroduce 1.0.4's bug), plus server-side geometry validation and an error state for tile failure.
5. Rollout. Enable on one internal-only resource, then widen.

Fallback. If the spike fails, the cost to replicate is modest: a JSON column, a Nova field wrapping a Leaflet polyline editor, and a validation rule. That is a ~2–3 day build with no external dependency, which sets a hard ceiling on what this package is worth adopting.

Operational Impact

Maintenance. Every Nova upgrade becomes a compatibility question we may have to answer ourselves. With a single maintainer and no dependents, assume we will eventually fork; budget for that rather than discovering it during a Nova 6 upgrade. Dependency drift in the bundled JS mapping library is the more likely breakage than the PHP side. The 1.0.4 patch is evidence the maintainer is still responsive to correctness bugs on a 1.0 line — encouraging, but it is one data point on a package with no test signal we can inspect.

Support. There is no community to lean on and no issue history to search. Internal documentation — storage format, tile provider config, the null-geometry behavior, how to patch the fork — must be written at adoption time, not deferred. Name an owner.

Scaling. The PHP side is negligible: one field on one resource, plus a comparison callback per form render. The load is client-side — rendering and editing large MultiLineString geometries (thousands of vertices) will tax the browser, and tile requests scale with editor usage, not with record count. If geometries are large or numerous, plan on simplification/serving vector tiles rather than shipping raw GeoJSON to the admin.

Failure modes.

• Tile provider outage or key expiry — editor renders blank; geometry becomes uneditable until the provider recovers or the key is rotated.
• Malformed GeoJSON — client-trusted persistence means a bad payload can poison a row; needs server-side validation and a read-only fallback view.
• Null geometry on create — fixed in 1.0.4; a live hazard on any pinned ≤1.0.3, and a regression risk if we bump the pin without re-testing the create path.
• Nova major upgrade — custom field component fails to compile or mount, or the attribute-comparison hook changes signature; field disappears from resource forms.
• Asset build drift — if assets are source-only, a host-app bundler change silently breaks the field.
• Abandonment — no upstream patches for a browser-facing editor; treat as a fork candidate from day one.

Ramp-up. For a Laravel/Nova developer, low — an afternoon to wire and test. The real ramp-up is domain literacy: whoever owns the field must understand GeoJSON coordinate ordering ([lng, lat]), SRID assumptions, Nova's field-comparison lifecycle, and what a valid MultiLineString means for downstream consumers. That knowledge is the durable asset here; the package itself is replaceable.