Nova Address Field Laravel Package

Technical Evaluation

Architecture fit. Nova field packages are thin, single-purpose extensions: a PHP Field subclass that registers a Vue component, plus compiled JS/CSS published into Nova's asset pipeline. This one wraps Google Places Autocomplete around a text input. It fits cleanly into a Laravel monolith using Nova as the admin surface — no service, no queue, no persistence layer of its own. The coupling is entirely to two fast-moving external contracts: Nova's internal field API and Google's Places JS API. Both have moved substantially since the April 2019 release.

Integration feasibility. Feasible only on a legacy stack. The 2019 release date implies Laravel 5.7–6.x, Nova 1.x/2.x, Vue 2, and laravel-mix. Nova 4+ (Vue 3/Inertia, Vite) breaks the component and asset registration model; Nova 5 breaks it further. Verify composer.json constraints before anything else. On a current stack (Laravel 11/12, Nova 4/5), assume it will not install or will not render.

Technical risk.

• Abandonment (high): last release 2019, 10 stars, single maintainer. No security patching and no response to Nova or Google API drift.
• Google Places API drift (high): legacy google.maps.places.Autocomplete is deprecated in favor of the new Places API (AutocompleteSuggestion / PlaceAutocompleteElement). Behavior, billing model, and SKU pricing all changed in 2025.
• Key exposure (medium-high): a browser-side Maps key must be HTTP-referrer restricted and API-restricted. A leaked key with Places enabled is a direct billing liability.
• Data model ambiguity (medium): unclear whether the field persists a formatted string or structured components (street, city, postcode, country, lat/lng, place_id). For reporting, validation, and downstream geocoding, a flat string is usually the wrong shape.
• Supply chain (low-medium): small package, but unmaintained transitive dev dependencies for its asset build.

Key questions.

1. Which Laravel and Nova versions must this run against?
2. Does the field persist a formatted string, JSON, or discrete columns — and is place_id retained?
3. Are Autocomplete session tokens used (the major billing lever), and are Place Details calls made client- or server-side?
4. Is the Maps key server-configurable, and is there any documented restriction guidance?
5. Are there tests, and is there a fork/ownership plan?

Integration Approach

Stack fit. Good fit only for Laravel ≤6 + Nova 1.x/2.x, an internal admin form needing a single free-text address input, and a team already holding a billed Google Maps key. Poor fit for anything modern or customer-facing.

Migration path. Two viable routes:

• Fork-and-own: vendor the package, relax composer.json, rewrite the Vue component for Nova 4/5 (Vue 3, Inertia, Vite), and port to the new Places API. Scope is genuinely small — a field class, one Vue component, and asset registration — likely 2–5 days for a mid-level Laravel developer plus review.
• Replace: build the field natively or select a maintained alternative. Given the surface area, native is usually cheaper than rehabilitating an abandoned package.

Compatibility. Verify in order: PHP constraint → Laravel constraint → nova constraint → asset registration mechanism (Nova::script/Nova::style vs. Nova 4's npm-published component model). Treat any mismatch as a fail-fast gate, not a patch target.

Sequencing.

1. Version audit — confirm current Laravel/Nova. If Nova ≥4, the decision is build-vs-fork, not adopt-vs-reject.
2. Source review — read the field class and Vue component end to end; document the storage shape.
3. Billing setup — dedicated Maps project, key restricted by HTTP referrer and API (Places only), budget alerts and quotas configured.
4. Data model — decide columns (formatted address, structured parts, place_id, lat/lng) before writing UI.
5. Implement or fork, then add a test covering the field's fill/resolve behavior.
6. Roll out behind a feature flag on one form; monitor Places request volume for a week.

Operational Impact

Maintenance. Effectively zero upstream — treat total cost of ownership as internal. Budget a review at each Nova major and each Google Places API change. Pin the fork to a commit and record the rationale in-repo.

Support. No vendor, no SLA, and 10 stars means no community depth; Stack Overflow will not rescue you. Every incident is self-served. Write the failure modes into the runbook explicitly.

Scaling. Cost scales with typing, not users: every keystroke-triggered request is billable unless debounced and session-tokened. Fine for internal admin traffic; unsuitable for bulk import or customer-facing volume. Mitigate with autocomplete session tokens, ~300ms debounce, a 3-character minimum query length, and server-side caching of Place Details by place_id.

Failure modes.

• Key invalid, referrer mismatch, or quota exhausted → autocomplete dies silently; the field degrades to plain text. Decide explicitly whether that is acceptable or should block submit.
• Google API contract change or deprecation → component throws in console while the form still submits garbage.
• Nova upgrade → field fails to render, potentially as a white-screen form.
• Key leakage → uncapped billing; the only mitigations are restriction and budget alerts.
• Validation gap → invalid strings accepted because Places matched something.

Ramp-up. Low for a Laravel developer to read the code (hours). Higher for surrounding context: Nova's field lifecycle, Google Places billing semantics, and Vue 2→3 if forking. Plan half a day of onboarding plus a Maps billing walkthrough.

Recommendation. A score of 2.70 with opportunity at 4.17 reads as real demand, poor execution. Do not adopt as a dependency. If the need is current and the stack is legacy, fork it with a named owner and a bounded effort; otherwise build the field natively and spend the saved integration risk on getting the data model and key restrictions right.