alexbowers/nova-prepopulate-searchable
A Laravel Nova package that lets you prepopulate searchable relationship fields from URL query parameters, making it easier to create records with preselected BelongsTo values from links or filtered lists.
Architecture fit. This is a Laravel Nova frontend extension, not a general-purpose Laravel library. It targets a single, narrow gap: Nova's BelongsTo field with searchable() renders an empty select until the user types, so there is no way to show a pre-selected related record (or its label) on form load — a common need when creating a child record from a parent's detail page via a query parameter, or when defaulting an owner/tenant/category. Architecturally it plugs into Nova's custom-field mechanism (a PHP Field subclass plus a compiled Vue component registered through Nova.booting), which means it lives inside Nova's private frontend contract rather than on a stable Laravel API. That is a thin, single-purpose fit: it solves one UX papercut and adds no server-side domain logic. For a TPM this is a "convenience dependency," not an architectural component — it should never be load-bearing.
Integration feasibility. Mechanically easy: composer require, then swap BelongsTo::make(...)->searchable() for the package's field class. No migrations, no service providers of consequence, no data model changes, no queue or config surface. The real feasibility question is version alignment, not effort. The package's last release is February 2022 and the repository is archived, which places it in the Nova 3 / Laravel 8 era. Nova 4 moved to Vue 3 + Inertia and rewrote the field component lifecycle; Nova 5 continued that line. A Vue 2-era field component will not boot under Nova 4+, and a Laravel 8-era composer.json constraint will usually conflict with Laravel 10/11/12. Expect integration to be a fork-and-port exercise rather than an install.
Technical risk. High, and concentrated in three places:
BelongsTo means writing a foreign key without a user selection. If the value is derived from a query string, the risk surface includes tampering (a user setting ?owner_id= to an arbitrary ID), multi-tenancy leakage (pre-filling a record from another tenant), and policy bypass (the option is displayed even though the user lacks viewAny on the related resource). None of that is the package's job to enforce — but the package makes the unsafe pattern easy and the safe pattern undocumented.Note also the low composite score (0.3775) and star count: essentially no community validation, no third-party blog posts or Stack Overflow corpus, so every problem you hit is yours alone.
Key questions.
->default(), ->resolveUsing(), ->withMeta(['options' => ...]), or the dependsOn field? If yes, the package is unnecessary.Stack fit. Compatible only with the narrow band of Nova 3.x on Laravel 8/9 with PHP 7.4–8.1. If the platform is on Laravel 10/11/12 with Nova 4/5, treat this as not installable as-is. Because it is MIT-licensed, forking and vendoring is legally clean and the pragmatic default — but only after confirming the native-alternative question above, since reimplementing may be cheaper than porting.
Migration path. Recommended sequence for a Nova 3 shop: (1) install into a scratch branch, (2) replace one BelongsTo field on a low-traffic resource, (3) verify the label renders on load, the value persists on save, and the field behaves correctly when the pre-populated record is later deleted, (4) expand to remaining fields, (5) immediately vendor the package into the repo (path repository or a packages/ directory) so Composer cannot silently lose it and so you own the patch surface. For a Nova 4/5 shop: skip installation; budget a spike to port the Vue component to Vue 3, or better, spend the same spike confirming native Nova support.
Compatibility. Two axes to test explicitly. Framework: pin laravel/nova and confirm the composer.json constraint does not force a downgrade of Laravel or PHP — a conflict here usually surfaces as an unrelated package being held back, which is a common and confusing failure. Frontend: confirm the field's compiled assets load under the current Nova asset pipeline; Nova 4+ publishes assets differently and a stale nova.mix-era build will fail at boot. Also test in a production build, not just npm run dev — Nova's dev/prod asset divergence hides breakage.
Sequencing. Do the native-alternative investigation before any code work — it is a few hours and can eliminate the entire dependency. If the package survives that gate, port/fork first, then integrate, then harden. Hardening (the part the package does not do) belongs in the same ticket, not a follow-up: server-side authorization on the pre-filled ID, tenant scoping, and re-validation in the StoreRequest/UpdateRequest so the foreign key is always re-checked regardless of what the form displayed. Treat the package as presentation-only sugar over a value the backend must independently validate.
Maintenance. Effectively zero upstream, so all maintenance is yours. Budget a standing allowance of roughly 1–2 developer-days per Nova major upgrade plus reactive time on minor releases that touch the field internals. Vendor the fork with a clear README noting the divergence from upstream and the Nova version it targets; without that, the next developer will composer update and discover the fork's provenance the hard way. Low star count also means no upstream test suite worth trusting — write a smoke test (or at minimum a documented manual check) for "field renders with label" and "field saves the right ID."
Support. No vendor, no maintainer, no SLA. Internal support burden falls on whichever team owns the Nova admin panel — typically a small platform or ops group, which means bus-factor risk. Document the fallback: if the field breaks, temporarily reverting to plain ->searchable() degrades UX but does not lose data, which is an acceptable stopgap. Escalation path is "fork it ourselves," so the on-call runbook should say so plainly rather than pointing at a dead repo.
Scaling. Negligible in the traditional sense — this is admin-panel UI, off the request path for end users, with no queues, caches, or storage. Scale risk is organizational, not technical: only a handful of users touch Nova, so a regression may go unnoticed for days. The one scaling-adjacent concern is option resolution for large related tables — a pre-populated searchable field that eagerly loads options can be slow if the related resource has a large or unindexed display column. Verify the lookup is a primary-key fetch, not a scan.
Failure modes. Ranked by consequence: (1) JS boot failure — a Vue 2 component under Nova 4 can throw during Nova.booting and blank the admin panel; this is the worst case and argues strongly for a staged rollout. (2) Silent empty field — the select renders but shows no label, so the user believes nothing is selected and re-picks or saves null; data-integrity risk with no error. (3) Stale label — record renamed or deleted, and the field displays a stale or blank label while the foreign key still points at it. (4) Unauthorized pre-fill — a crafted URL pre-selects a record the user should not see, with the package surfacing the label without a policy check. (5) Composer drift — an unrelated composer update removes or downgrades the package, silently changing form behavior. Mitigate (1) with staged rollout, (2) and (3) with a regression check, (4) with backend re-validation, and (5) with vendoring.
Ramp-up. The codebase is small and a Laravel developer can read it in an afternoon; the barrier is Nova familiarity, not package complexity. The people who can debug it are the ones who already understand Nova's custom-field lifecycle and asset pipeline — likely one or two engineers. Plan for that concentration: have the fork owner write a short internal note covering what the field overrides, which Nova internals it touches, and how to test it. Given the size and the archived status, the honest strategic read is avoid as a dependency, absorb as a fork — or better, delete it entirely if the current Nova version covers the use case natively.
How can I help you explore Laravel packages today?