Nova Geolocation Field Laravel Package

Technical Evaluation

What it is. A Laravel Nova custom field package (gabelbart/nova-geolocation-field) that renders a map-based input inside a Nova resource form, intended to let an admin pick or confirm a latitude/longitude coordinate (and possibly an address) rather than typing raw numbers.

Architecture fit. Nova fields are a well-defined extension point: a PHP class extending Laravel\Nova\Fields\Field plus a compiled Vue component registered as the field's component. This is a shallow, low-blast-radius integration — it touches only the Nova presentation layer and one or two model columns. It does not intrude on routing, auth, queues, or the domain model. Architecturally, a map picker is a legitimate convenience feature, not a load-bearing dependency; if it disappears, the underlying data is still plain coordinates and the resource remains editable via a text input. That is the strongest argument in the package's favor.

Integration feasibility. Mechanically straightforward for anyone who has shipped a Nova field before: composer require, register the field in the resource, ensure the field's compiled JS asset is present or built, add a json/decimal/point column or two, and wire fillUsing/resolveUsing if the storage shape differs from the package's assumption. The unknowns are the storage contract (single lat,lng string vs. two columns vs. GeoJSON vs. address string) and whether the field validates coordinate ranges on the server or trusts the browser. Neither is documented in the metadata provided.

Technical risk — elevated, and dominated by provenance rather than code quality.

• Zero social proof. Empty star count, zero dependents, zero score. No downstream project has validated that this works against any real Nova version. There is no evidence of a maintainer, no release cadence, no CI badge.
• Provenance ambiguity. The package name (gabelbart/...) and the repository URL (gitlab.com/jacobfricke/...) point at different owners. This is either a fork, a rename, or a mis-scraped record. Before any evaluation, we need to know which artifact we would actually install and whether the GitLab repo is the upstream, a mirror, or an abandoned fork. Composer will pull from Packagist by vendor name; the GitLab URL may be irrelevant to what lands in vendor/.
• Nova version coupling is a hard cliff. Nova 3 is Vue 2; Nova 4 and 5 are Vue 3 with a rebuilt asset pipeline and a different laravel-nova npm toolchain. A field package compiled against the wrong major will either fail to mount, throw at build time, or silently render nothing. A package with no releases and no issue history almost certainly targets exactly one Nova major, and probably an old one.
• Commercial dependency. Nova itself is a paid, license-gated product with its own upgrade cadence. We inherit a transitive constraint: this field must be re-validated on every Nova upgrade, and we cannot patch Nova if the field breaks against it.
• Third-party map provider. A geolocation widget implies Google Maps, Mapbox, Leaflet/OSM, or similar. That brings an API key into the admin UI (a browser-visible key needing referrer/referrer-IP restrictions), a billable quota, and — if reverse geocoding is involved — per-keystroke cost and latency. None of that is visible from the package metadata.
• Licensing. No license is stated. Absent an explicit LICENSE file, default copyright applies and commercial use is legally murky. That alone can be disqualifying for a client-facing engagement.
• Supply chain. An unmaintained, zero-dependent package is exactly the profile that doesn't get security advisories and doesn't get flagged by tooling. We would be the only party reviewing its diff.

Key questions to resolve before committing.

1. Which repository is canonical, and is the Packagist vendor the same entity as the GitLab owner?
2. What is the declared Nova version constraint (nova in composer.json), and does it match our Nova major today and on our upgrade roadmap?
3. Is a prebuilt field.js shipped, or must we run the laravel-nova npm build ourselves? Does it build against our Node/Vite versions?
4. What is the storage contract — column type(s), serialization format, precision — and does the field handle nulls, partial input, and out-of-range coordinates server-side?
5. Which map provider, is the key supplied by config or hardcoded, and does it call a geocoding API (cost, rate limits, PII)?
6. License terms.
7. What is the true adoption cost versus writing a ~150-line Nova field ourselves in one to two days?

Recommendation. Treat this as a build-vs-buy spike, not a procurement decision. The feature is small and well-bounded; the package is unvalidated, possibly misidentified, and possibly pinned to an EOL Nova major. Unless a 30-minute spike proves it installs cleanly against our Nova version and stores data in a shape we already want, the correct TPM call is to rebuild the field in-house against our own storage contract — we keep the map provider, the key handling, and the upgrade path under our control.

Integration Approach

Stack fit. Requires Laravel + Nova (paid) + a JS asset pipeline capable of producing the field component. Fits cleanly only if we already run Nova in the target application; if Nova is not already in the stack, this package is not a reason to adopt it — a standalone map picker in a standard Blade/Livewire form would be simpler and cheaper.

Compatibility gates, in order. (a) Nova major version vs. package constraint; (b) PHP and Laravel version constraints in composer.json; (c) presence and freshness of a compiled dist/js/field.js; (d) Node/npm build chain compatibility if we must compile; (e) database driver — MySQL POINT vs. Postgres geography vs. plain decimal(10,7) columns behave differently and POINT typically requires raw expressions the field won't generate for us.

Migration path. Low-risk and reversible if scoped correctly:

1. Add nullable latitude/longitude (decimal(10,7)) columns — nullable and additive, safe on large tables with online DDL.
2. Backfill from any existing address/coordinate text columns via a one-off geocode job, writing to the new columns; never overwrite the source until reconciled.
3. Present the field read-only or on a staging resource first; compare rendered values against raw column values for a sample of records.
4. Flip to editable for a pilot group of admins, keeping the raw numeric inputs visible as a fallback during the pilot.
5. Only after a full Nova upgrade cycle passes do we drop the fallback inputs.

Sequencing relative to other work. Do not couple this to a Nova major upgrade. Land it either well before or well after, so a field breakage is not confused with an upgrade regression. If a Nova upgrade is already scheduled, sequence the upgrade first, then evaluate the field against the new major — otherwise we validate against a version we're about to leave.

Preferred variant if adopted. Vendor the fork: point Composer at our own GitLab/GitHub mirror via a vcs repository entry, pin to a specific commit SHA (not a branch), and commit the compiled asset. This gives us a patch surface and protects against upstream deletion.

Operational Impact

Maintenance. Effectively zero upstream maintenance to rely on, which is the problem. We should assume we own the code from day one: budget for patching it on every Nova upgrade, and for auditing it on every Laravel/PHP minor that touches the asset pipeline. Realistic ongoing cost is small but non-zero — a few hours per Nova upgrade cycle, plus unpredictable time if the Vue component breaks in a way that requires reading someone else's source.

Support. No vendor, no SLA, no visible issue activity. Internal support falls to whichever engineer owns the Nova admin. Document the field's storage contract and the "how to edit coordinates by hand" escape hatch in the runbook — that single paragraph converts a hard outage into an inconvenience.

Scaling. The field itself is presentation-layer and adds negligible server load. The scaling surface is external: map tile loads and any geocoding calls scale linearly with admin session count and with keystroke/input frequency. Reverse geocoding on every marker drag is the classic cost trap. Mitigate by geocoding only on explicit confirm, caching results by coordinate rounded to ~5 decimal places, and setting a hard quota alert on the provider account. Also watch admin-page payload: map SDKs are heavy and will noticeably slow the resource index/edit page on high-latency connections.

Failure modes to design around.

• Map provider outage or quota exhaustion → field renders blank or uneditable; require the raw numeric inputs to remain as a fallback so records can still be created.
• Missing, expired, or referrer-misconfigured API key → silent blank canvas, frequently misdiagnosed as a code bug. Surface a visible error state.
• Nova upgrade → component fails to mount; the form may still submit with coordinates unchanged or null. Guard with server-side validation, not client-side only.
• Coordinate round-trip drift → string vs. float coercion producing 0.0000000 or truncated precision on save. Validate range (-90..90, -180..180) and precision server-side and assert it in a test.
• Ambiguous geocode → wrong-but-plausible coordinates saved without review. Require a human confirm step rather than auto-filling from a free-text address.
• Upstream repo deletion or force-push → mitigated only by the vendor/pin strategy above.
• Undeclared license → legal exposure; resolve before production, not after.

Ramp-up. For an engineer already fluent in Laravel and Nova, the field's public surface is perhaps half a day to learn; the real cost is the unglamorous part — reading an undocumented, unmaintained Vue component to understand its storage assumptions and its behavior on edge inputs. Estimate one to two days to evaluate and harden, versus roughly one to two days to write a clean equivalent in-house with a storage contract we chose. That parity is the decisive operational fact: we are paying integration and ownership cost for a package that saves us almost no engineering time, and carries provenance, licensing, and upgrade-cliff risk we would not otherwise have.

Net operational posture. Acceptable only as an internal convenience in a non-critical admin surface, vendored and pinned, with a hand-edit fallback and server-side validation. Not acceptable as a dependency in a client-delivered or long-lived product without first resolving the canonical-repo and license questions and confirming Nova-major support.