Product Decisions This Supports
- Feature enablement: Adds a geographic point-of-interest field to Laravel Nova admin panels — pick a location on a Leaflet map, persist lat/lng, render it back on detail views. That is the entire scope, and it is the right scope for a first geo feature.
- Roadmap prioritization: Lets you ship "location" as a thin admin-layer capability instead of a platform initiative. If your roadmap has "store/branch/property/venue locations" or "service area coverage," this is a days-not-quarters path to a working internal tool.
- Build vs. buy vs. skip: The honest framing is buy the Nova license, borrow the field, own the maintenance. Leaflet is free and BSD-licensed, so this avoids Google Maps Platform per-load billing and API key governance — a meaningful line-item decision for a product with internal-only mapping needs.
- Release 1.1 changes nothing about the above: the sole change is the vendor name moving from
otrsw to imumz. No new features, no bug fixes, no framework compatibility work. Treat it as housekeeping, not as a signal of renewed investment — the roadmap math from the prior release is unchanged.
- Representative use cases: Property and asset listings, store/branch locators (admin-side), delivery or service zones (pin-based), field-sales territory assignment, event venue management, incident/facility registries, warehouse and logistics reference points.
- Dependency and risk decisions: With 8 stars, zero dependents, and a prior release in January 2021, adopting this is a vendor-your-own-fork decision, not a procurement decision. Release 1.1 sharpens that read: the first thing upstream shipped in years was a rename of its own handle. That is a bus-factor data point, and it belongs in your risk register and your tech-debt backlog — not in a "looks nice" column.
- Package identity is now a migration item: the vendor rename means the Composer package name (and any matching namespace) changed. If you piloted the old name, this release is a breaking change for your
composer.json — small, but it is your first maintenance task and it happens before you have written a line of product code. Pin the new name explicitly.
- Cost architecture: The package pushes you toward OpenStreetMap tiles and free-tier geocoding. That is cheap now and constrains you later if volume grows (tile usage policies, Nominatim rate limits). Decide deliberately whether "free maps" is a product constraint or a temporary shortcut.
When to Consider This Package
Adopt when all of these are true:
- You are already on Laravel Nova and have no appetite to migrate admin tooling.
- The requirement is a single point on a map — a pin picker with lat/lng persistence — not polygons, routing, clustering, or spatial queries.
- You accept that you become the maintainer. Budget a fork, a version pin, and a compatibility test against your Nova major version (this field predates Nova 4's Vue 3 stack; verify before you commit). Note the 1.1 vendor rename when pinning — install under
imumz, not the old otrsw name, and scrub the old name from any existing lockfile, autoload config, or copied source.
- The audience is internal operators, where a degraded or offline map tile is an inconvenience rather than a customer-visible outage.
- You want to validate demand for geo features before investing in a real GIS layer.
Look elsewhere when any of these are true:
- You are not on Nova — Filament, Livewire, or Inertia stacks have their own map fields; do not contort your admin stack to reuse this.
- You need reverse geocoding, address autocomplete, boundary drawing, heatmaps, or distance calculations. Those are separate integrations (Nominatim, Mapbox, PostGIS) and this package does none of them.
- You need a maintained dependency with a support path, a security response process, or an upgrade guarantee. A release whose entire content is a vendor rename does not change this answer.
- Mapping is customer-facing or revenue-critical. Free OSM tiles under a thin abandoned wrapper is not a production posture.
- Your team has no PHP/Vue capacity to patch a Nova field in place. The code is small; the willingness to read it is the actual prerequisite.
How to Pitch It (Stakeholders)
To executives: We can add location awareness to our internal admin in roughly one engineering sprint, with no per-map-load licensing fees and no new vendor contract. The trade-off is that the underlying component is a small community-published add-on — effectively unmaintained, and its most recent release was nothing more than a rename of the publisher's own handle. We should treat it as code we adopt and own rather than software we buy. Recommendation: green-light it for an internal tool or a discovery spike, keep the mapping layer abstracted behind our own field so a swap is a one-file change, and revisit if usage moves outside the back office. The 1.1 release does not change this recommendation; it is the evidence for it.
To engineering: This is a thin Nova field wrapping Leaflet — small surface area, easy to fork into our codebase and vendor outright, which is almost certainly the right move over a Composer dependency (and sidesteps the 1.1 vendor rename entirely, since you will not be resolving the package by name at all). If you do take it as a dependency, install under the new imumz vendor name, pin it, and confirm no otrsw references linger in your lockfile or autoload config. Read the source before adopting: confirm the Nova major version and Vue version it targets, confirm the PHP constraint against our runtime, and check how it persists coordinates. If it passes that read, the real work is not integration but choosing a tile provider we can live with and deciding where geocoding lives. Do not let it become a hidden dependency in a customer-facing path without a replacement plan.