- What is wm/map-multi-linestring used for?
- It is a Laravel Nova custom field for capturing and persisting GeoJSON MultiLineString geometries, such as multi-segment routes, corridors, pipelines and service paths, through an interactive map editor inside the Nova admin. Use it when Nova is already your admin layer and the domain genuinely needs multi-segment lines rather than a single polyline or a simple lat/lng pair.
- Do I need Laravel Nova to use this package?
- Yes. The backend is a Nova Field subclass plus a compiled Vue component registered as a custom field asset, so the package only makes sense if Nova is already your admin layer. Without Nova it is the wrong tool regardless of code quality, since there is no standalone map rendering or geometry editing API described.
- How do I install wm/map-multi-linestring with Composer?
- It is Composer-installable under the wm/ namespace, so adoption is a one-line dependency plus a field declaration on your Nova resource. Because there is only a single release, pin the exact version (for example 0.1.x or the specific tag) instead of a caret range, which buys nothing and forfeits reproducibility. Then confirm whether assets ship pre-built or must be compiled with your host app's toolchain.
- Which Laravel and Nova versions does it support?
- The available evaluation material does not state which Laravel or Nova versions are declared in composer.json, so check that file before adopting. Nova 4 and Nova 5 differ materially in their asset pipelines, so verify your major version is explicitly supported. Treat any combination that is not declared as an unverified spike rather than a drop-in.
- Does it work with Nova 4 and Nova 5?
- Compatibility with either major is unconfirmed in the available information; the package has a single release and no dependents that would demonstrate it working outside the author's own Nova install. Inspect composer.json for declared Nova constraints and test against your pinned version first. If assets are source-only, also confirm your build toolchain (Vite vs Mix, Node version) can compile the component.
- How is the MultiLineString geometry stored in the database?
- The persistence contract is not documented in the material available: it could be raw GeoJSON in a JSON column, WKT, or a custom cast. Add a nullable JSON column, or a geometry column if PostGIS is in play, so existing rows stay unaffected. Verify the value round-trips cleanly through the field before relying on it in production.
- Which mapping library and tile provider does it use, and do I need an API key?
- The field renders third-party map tiles, so it hard-depends on whichever JavaScript mapping library it bundles, such as Leaflet, Mapbox or Google, each with its own API keys, licensing and rate limits. Confirm which provider is used and whether you must supply your own key before rollout. These external dependencies also affect offline behaviour and long-term licensing costs.
- Is the GeoJSON validated on the server or trusted from the client?
- The editor parses user-supplied GeoJSON in the browser, so the XSS surface in the editor and malformed-geometry handling are genuine concerns. Whether server-side validation exists for closed rings, coordinate bounds or SRID is not documented, so assume client-trusted until you verify. Add your own validation rule if the geometry is business-critical.
- Is wm/map-multi-linestring production-ready and actively maintained?
- It is a single-maintainer, zero-adoption artifact with one release dated 2025-05-21, no dependents and no issue history to mine. Bus factor is effectively 1, and there is no evidence of sustained maintenance, test coverage or CI. Treat it as an unverified spike, not a drop-in dependency, and consider whether you could fork and own it.
- Does it support read-only display mode, and what are the alternatives?
- Whether the field supports a read-only or display-only mode, and how it degrades when the map fails to load, is not documented in the available material, so test both paths explicitly. It is a poor fit for high-volume geometry ingestion, public-facing map rendering, or pipelines fed by GIS tooling; those belong in PostGIS with a proper spatial layer, with this field as an optional manual-correction UI. For simple cases a single polyline or a lat/lng pair may be enough.