Nova Map Marker Field Laravel Package

Technical Evaluation

Architecture fit. This is a Nova field, not a platform — a sanctioned, narrow extension point consisting of one PHP field class extending Laravel\Nova\Fields\Field, one compiled Vue component, a service provider, and published assets/config. It introduces no domain models, migrations, routes, queues, or scheduled jobs, and touches neither authentication nor authorization. The change surface is one line in a Nova resource definition plus a config entry. Leverage is asymmetric in the right direction: low install cost, low removal cost, blast radius describable to a non-technical stakeholder in one sentence. The correct TPM posture is to scope, price, and govern it as a widget — not to file it under "geo platform."

Integration feasibility. Mechanically the path is short: composer require, publish config, set a Google Maps API key, add the field to a resource. The gates that actually decide the outcome are environmental and contractual, and each has lead time:

• Nova license dependency. Nova is a paid first-party product. The package has zero value outside a shop with an active license, which narrows the addressable estate immediately. This is the first qualifying question in any evaluation, not the last.
• Third-party map contract. Google Maps JavaScript API implies an API key, a billing account with payment method, ToS acceptance, and a CSP/tile-terms review. That is procurement and legal work, not a composer command.
• Nova major-version coupling. Nova field packages bind tightly to Nova's embedded Vue runtime. Nova 4's move to Vue 3 broke a large share of Nova 3-era fields. This release predates that shift, so compatibility is the deciding technical risk rather than a footnote.
• Storage contract ambiguity. The description claims coordinates are saved to latitude/longitude fields; implementation notes describe a single JSON column holding {lat, lng}. A TPM must force this to a written answer before anyone authors a migration, because it determines whether downstream reporting, indexing, and a future PostGIS migration are cheap or a re-platform.

Technical risk. Concentrated in one verifiable fact: the package is archived, last released 2022-06-17 — roughly two Nova majors and several PHP/Laravel majors ago. No patches, no compatibility releases, no security advisories, no issue triage. Supporting signals are weak: 128 stars and 0 dependents means no observable population is running this against modern Nova, so our proof of concept would be the only test in existence. Offsetting factors are genuine: MIT grants clean fork and vendor rights, and the codebase is small enough (one field class, one Vue component, one map initialization) that a native rebuild is a credible estimate rather than a heroic one. High opportunity signal against abandoned supply is the classic underserved-niche signature — demand is real, this specific artifact is not the answer.

Key questions.

1. Which Nova major versions do the composer constraints permit, and which do our target apps actually run today?
2. Is the JS bundle precompiled and committed, or must we stand up a legacy Node/Vue toolchain to build it — and can we support that toolchain?
3. Which map provider and JS library are bundled, and what are the key, billing, CSP, and tile-terms implications?
4. What is the actual storage contract — discrete decimal lat/lng columns or a single JSON blob — and at what coordinate precision?
5. Does it render on index and detail views, or forms only? Per-row map initialization on an index view is a direct quota burn.
6. Is there a maintained fork or successor package, or do we own this outright from day one?
7. What is the CVE posture of the bundled transitive JS dependencies, and can we audit them?

Integration Approach

Stack fit. Binary. If the estate is Laravel + Nova with an active license, this is a plausible 1–3 dev-day convenience per project. If the team runs Filament, a bespoke admin panel, or headless APIs, fit is zero and the evaluation ends at that sentence. The opportunity score reflects a thin market of Nova map-picker options, not broad applicability — do not let it leak into prioritization outside Nova.

Migration path. There is no traditional schema migration; the field is additive and removable. But there is a data-model commitment, and it is the one-way door: a JSON {lat, lng} blob versus discrete decimal columns changes how you query, index, and later migrate to a spatial type. That decision belongs at the gate, framed as adopt / fork / rebuild:

• Adopt as-is — viable only if a pinned Nova version already matches and the PoC round-trips cleanly. Lowest effort, highest tail risk; acceptable only for throwaway internal tooling.
• Fork and vendor — push to a private Packagist or VCS path repository, pin the version, patch the Vue component against our Nova version, and treat it as internal code. Converts an unmaintained dependency into an owned one at modest, estimable cost.
• Rebuild natively — the surface is one field component plus a coordinate column pair. A competent Nova developer reproduces this in 2–5 days against our exact Nova version, with no legacy toolchain and no upstream risk. For a team running multiple Nova apps, this is likely the cheapest long-run option and must be priced on the table at the decision gate, not after.

Compatibility. Pin Nova, PHP, and Node explicitly in both the composer constraint and the CI matrix. Verify the published asset path matches what our Nova version's asset pipeline expects. Test the full round-trip — create, update, detail, index — not just the happy-path form render. Treat "renders a blank map" as an expected failure mode and assert against it.

Sequencing.

1. Inventory Nova major versions and license status across target apps; kill the evaluation if no Nova 3.x-era install exists.
2. Read the small source: audit JS dependencies, confirm map provider, confirm the storage contract, check marker-label escaping.
3. Branch a proof of concept on staging with a throwaway resource; validate coordinate round-trip precision and rendering across views.
4. Decision gate: adopt, fork, or rebuild — with the native rebuild estimate explicitly on the table.
5. If forking: register in the internal fork index, name an owner, add a CI smoke test asserting assets resolve, set an annual review date.
6. Roll out to one app, then template the pattern for the rest.

Operational Impact

Maintenance. The dominant cost, and the one that must show up in the business case. An archived package with no upstream means every Nova upgrade, PHP upgrade, or Google Maps API change lands on us. Budget a named owner, a pinned version, a vendored fork under source control, and a recurring line item — roughly 1–2 days per year of stewardship in a quiet year, materially more in any year that Nova ships a major. The alternative framing is cleaner: the native rebuild's 2–5 days is the maintenance budget amortized forward, with the abandonment risk eliminated rather than managed.

Support. There is no vendor, no maintainer, and no issue backlog to escalate into. Internal support means the owning team reads the source — realistic here given its size. Document the Google Maps key rotation procedure and the config surface in the runbook; the most common support ticket will be "the map is blank," and the answer will almost always be key, billing, CSP, or config rather than code.

Scaling. Two axes. Technically, the field is per-record and stateless; it scales with page views, not data volume — the constraint is Google Maps JS API quota and billing, which scales with admin usage and especially with index-view rendering. Keep the field off index views unless there is a specific need. Organizationally, the pattern scales well: once one resource uses it, templating it across a dozen resources is nearly free, which is precisely why the governance step (owner, pin, smoke test) must happen on the first install rather than the tenth.

Failure modes. Rank them and monitor accordingly:

• Silent blank map — the signature failure. No exception, no error page, just an empty div. Requires an active smoke test asserting assets resolve and a tile request fires.
• Nova upgrade breakage — renders in dev, dies on the next Nova major. Mitigate with version pins and a staging upgrade rehearsal.
• Quota/billing exhaustion — map dies mid-sprint when the Google billing account lapses or the key is unsecured.
• Data-model regret — six months in, someone needs distance queries and the coordinates are locked in a JSON blob. Solved by deciding the storage contract up front.
• Security exposure — unrestricted API key committed to the repo, or marker labels rendered without escaping. Both are cheap to fix on day one, expensive after an incident.

Ramp-up. Low and front-loaded. A Nova-fluent developer is productive in half a day: read the field class, read the Vue component, wire a throwaway resource. The genuine skill requirement is not this package but Nova frontend competence — a team without it should not operate an unowned fork of an archived package, which is a worse outcome than not adopting at all. Plan the ramp as: one developer, one PoC resource, one written decision record covering storage contract, map provider, key handling, and ownership — then expand. Total elapsed time from kickoff to a production resource should be under a week if the Nova version matches, and roughly a week if it doesn't and we rebuild.