Leaflet Map Laravel Package

Technical Evaluation

Architecture fit. imumz/leaflet-map (formerly otrsw/leaflet-map; release 1.1 renamed the vendor only) is still a Laravel Nova field, not a general-purpose Laravel package. Its entire value is a Vue form component that wraps Leaflet into Nova’s field lifecycle for capturing/displaying geographic coordinates. Fit remains binary: if the product runs on Nova, it is a candidate drop-in form field; if not (Filament, plain Blade, Inertia, API-only), it is unusable without a rewrite. The package carries no mapping service, geocoding, storage schema, or backend logic — it is a thin UI adapter. Treat it as a component, not a capability.

Integration feasibility. 1.1 changes nothing functional. There is no Nova compatibility work, no Vue/Vite build-chain update, no Leaflet bump, no dependency refresh, and no security patch — the diff is a vendor rename. That means the underlying code is still the January 2021 implementation, which places it in the Nova 2/3 era. Nova 4 moved to Vue 3 and changed field asset compilation; Nova 5 continued that line. A 2021 field package is very unlikely to load correctly under current Nova without modification, and the rename does not alter that. Two practical consequences of 1.1: (a) the Composer identity and namespace change, so any existing otrsw/leaflet-map constraint, lockfile entry, or class/asset reference breaks on upgrade — this is a breaking change for consumers even though behavior is identical; (b) a vendor rename often signals a maintainer handoff or repo transfer, which is worth verifying (who owns imumz, is the old namespace abandoned, does the Packagist entry redirect) before assuming renewed maintenance. The nominal path — composer require imumz/leaflet-map, register the field, add to a resource — remains trivial; the real work is still confirming it does not silently break the admin UI.

Technical risk. High, essentially unchanged. Signals: 8 stars, 0 dependents, a score of 0.1, and a single release since January 2021 whose only content is a rename. Zero dependents means no downstream validation and no one else surfacing breakage. A metadata-only release is not evidence of a maintenance commitment; it is the cheapest possible publish. The bundled JS remains a supply-chain surface that has not been audited or updated in years, and the rename is a supply-chain event in itself — a new vendor namespace now controls the package identity, so confirm the new owner is who we think it is before pulling. The Leaflet dependency is healthy; that does not transfer to this wrapper. Risk profile is still "abandoned micro-package that just changed hands or names": small enough to fork, not safe to consume as-is.

Key questions. Which Nova major version does the product run, and does this field’s Vue/Nova API surface match it? Which Laravel and PHP versions are supported, and does that intersect the current runtime? Who is imumz, is the rename a transfer of ownership, and does the old otrsw namespace still resolve or redirect? Does 1.1 ship a changelog, tagged commit, or signed release, or only a version bump? How does the field persist coordinates — separate latitude/longitude columns, a JSON blob, or a convention the rest of the schema does not use? Which tile provider does it default to, and does that comply with the provider’s usage policy and our API-key/egress model? What is the license, and does it permit an internal fork? Is there a maintained fork or a credible Nova-native alternative we should compare against before investing?

Integration Approach

Stack fit. Adopt only if the stack is Laravel + Nova and the field is genuinely needed for coordinate capture in an admin resource. If Nova is present but the mapping requirement is read-only display, a simpler static map or link may satisfy the need without any dependency. If the product is not on Nova, stop here — the correct answer is a different component, not this package.

Migration path. Do not consume upstream directly, and do not treat 1.1 as a reason to move. The defensible path is unchanged: pin the package into a private fork or vendored copy, bring the Vue/Leaflet code onto the current Nova field API, and own it. Fork from the 1.1 tag so the internal copy tracks the current vendor name, and record in the fork README that the upstream rename happened and that no functional changes accompanied it. The alternative — building the field in-house against Leaflet — is likely comparable effort and yields cleaner long-term ownership; the package’s value is mainly as a reference implementation.

Compatibility. Validate against the exact Nova, Laravel, PHP, and Node/Vite versions in the target environment. Front-end asset compilation is the most likely failure point: Nova 4+ expects Vue 3 and a different build chain than a 2021 package provides. The rename does not touch this. Additionally confirm that any internal references (Composer constraints, service providers, published assets, Nova field registration) are updated from otrsw to imumz — a mixed-namespace state will produce confusing load failures that look like compatibility bugs but are not. Also confirm the Leaflet version and tile-provider configuration, and check that the field renders in the target Nova theme and form layout. Treat "renders" and "saves" as separate tests.

Sequencing. (1) Confirm Nova version and the coordinate storage convention. (2) Verify the vendor rename: new owner identity, Packagist entry, license, and whether the old namespace is deprecated or redirected. (3) Time-box a spike: install in a branch, load the field on one resource, verify render, save, reload, and validation. (4) Decide fork vs. build vs. buy a maintained alternative based on spike results. (5) If forking, pin versions, adopt the imumz namespace in the fork, add the field to the internal component library, and document the Nova upgrade checklist. (6) Only then roll out beyond a single resource.

Operational Impact

Maintenance. Effectively zero upstream maintenance, so the burden is ours from day one. The 1.1 rename is a one-line change, not a maintenance regime; do not read it as a signal that Nova compatibility will be addressed. The codebase is small, which makes forking tractable, but every Nova upgrade becomes a manual compatibility review of this field. Budget for that review at each Nova major and for periodic Leaflet/tile-provider checks. Without an assigned owner, this field will drift out of compatibility and fail quietly.

Support. No vendor support, no active issue triage, no security responsiveness. Internal support means relying on whoever forked it. That person becomes a single point of failure unless the fork is documented and at least one other engineer can maintain it. The vendor rename adds a small support wrinkle: tickets and bookmarks pointing at the old otrsw repo may now be stale or redirected, so update internal references at the same time as the fork. Escalation paths for "the map field is broken in admin" terminate internally.

Scaling. Low concern. This is an admin form field, not a runtime hot path — it does not affect customer-facing throughput. Watch only for per-render tile requests and any geocoding calls if added later, which can create third-party rate-limit and egress exposure. Admin concurrency is the practical ceiling, and it is small.

Failure modes. Silent breakage on Nova upgrade (field renders blank or fails to save). Vue version mismatch causing the component not to mount. Namespace mismatch after the otrsw → imumz rename, producing class-not-found or unregistered-field errors that masquerade as compatibility failures. Asset build failures after a Node/Vite bump. Tile provider rejecting requests due to policy, key, or referrer changes. Coordinate write failures that pass validation but persist incorrectly. Each of these surfaces in the admin UI, not in application logs, so detection depends on user reports unless we add explicit smoke coverage.

Ramp-up. Leaflet itself is well documented and low-friction; the real ramp-up is Nova field development — the field lifecycle, asset registration, and Vue integration. Expect a few days for an engineer already familiar with Nova, longer otherwise. The package’s code is small enough to read end-to-end, which shortens onboarding. The larger cost is institutional: documenting the fork and the upgrade procedure so the knowledge does not sit with one person, and recording the vendor rename so future maintainers are not confused by two package names for the same code.

Recommendation. Do not adopt as a maintained dependency. Release 1.1 is a vendor rename with no functional, compatibility, or security content, so it does not change the underlying profile: an 8-star, 0-dependent package last materially updated in January 2021, with a 0.1 score. Either fork the 1.1 tag and own it as a small internal Nova field, or replace it with a maintained alternative or a modest in-house build. Before either, confirm who now owns the imumz namespace. Usable as a reference, not as a dependency.