Nova Order Field Laravel Package

Technical Evaluation

Architecture fit. michielkempen/nova-order-field is a presentation-layer extension for Laravel Nova, not an ordering engine. The distinction matters for how this gets scoped and sold internally: the field captures editor intent (drag, drop, persist) and writes a value to a sort column; it does not own ordering semantics. Ordering state belongs in a dedicated order/sort_order integer column on the Eloquent model, while scoping, visibility, publishing state, and any public-API sort contract stay in application-owned code. It fits where the product already runs Nova and needs manual ordering of flat editorial lists — navigation items, hero slides, FAQ entries, categories, product collections, galleries, prioritised queues. It does not fit nested hierarchies (multi-level menus, trees), per-locale/per-store/per-category ordering beyond what the model configuration already expresses, or any surface outside Nova. Because it is internal-only, it carries no customer-facing surface, no pricing implications, and no analytics instrumentation — keep it off the customer roadmap and cost it as developer time against an editor-experience benefit.

Integration feasibility. Nominal footprint is small: Composer install, register the field on one or two Nova resources, add and backfill an order column, attach the field with onlyOnIndex(). That is roughly 1–3 developer days cheaper than a hand-rolled Nova field, with no licence fee. MIT licensing and a narrow surface make vendoring or forking plausible if compatibility breaks. But feasibility is unproven against the current stack: last release January 2022, 59 stars, zero listed dependents, against a Nova major-version cadence that has moved several times since. A TPM should treat feasibility as an open question gated on a time-boxed compatibility spike, not an assumption carried into a roadmap commitment.

Technical risk. The primary risk is Nova version compatibility — changes to front-end assets, Vue/Inertia patterns, and asset publishing are the likeliest breakage points, and the failure mode there is admin UI regression rather than data loss. Secondary risks: reorder persistence behaviour (single-row update vs. bulk rewrite, transactionality, locking), authorization and multi-tenant scoping on the reorder endpoint, behaviour under filters/search/pagination, soft deletes, duplicate or sparse order values producing unstable drags, and silent save failures that leave the UI showing an order the database never received. Upstream is low-activity and effectively unowned, so the correct posture is internal fork candidate, not strategic dependency — tolerate and monitor, do not invest.

Key questions. Which Nova, Laravel, PHP, and browser versions are actually supported — Nova 4/5, or only Nova 3? How does it persist order changes: one row at a time, bulk rewrite, inside a transaction, with any locking? Does the reorder endpoint sit behind Nova middleware and respect the resource's update policy, and does it enforce tenant scoping? How does it behave on a filtered or paginated index — does a drag on page 2 of a filtered list produce a globally correct sequence? Is it keyboard- and mobile-accessible (drag-and-drop is a known a11y trap)? What is the pre-agreed fallback if it blocks a Nova upgrade? All of these are answerable in a one-day spike and should be answered before rollout, not after.

Integration Approach

Stack fit. Suitable only for Laravel applications already running Nova in production. Do not introduce Nova in order to adopt this field; the commercial licensing prerequisite across CI, staging, and contractor machines is frequently the real blocker, not the package. Use it for low-risk admin-side ordering. Avoid it as the mechanism for high-volume, transactional, or customer-facing ordering logic unless wrapped in application-owned services and endpoints.

Migration path. Pilot on a single non-critical Nova resource. Pin the Composer version explicitly, publish required assets, add the field onlyOnIndex() so editors cannot hand-edit raw order values in forms, and validate against realistic data before expanding to a second resource. Backfill existing rows to a clean 1..n sequence first — duplicate, null, or sparse order values produce unstable drag results regardless of package quality. If the spike shows incompatibility, fork: update the front-end assets for the current Nova major, keep the fork as documented internal code, and record the divergence. This is a cheap fork; budget it as a pre-approved option, not a failure.

Compatibility. Gate adoption on a compatibility spike against the exact Nova/Laravel/PHP matrix: Composer constraints, asset compilation and publishing, policy enforcement, multi-tenant behaviour, filtered-list reordering, soft-delete behaviour, and database constraints. Add a normal index on the order column; be cautious with unique constraints, since drag-reorder implementations commonly write temporary duplicates or update row by row. Confirm the resource's default sort matches the order column so the index reflects persisted order on reload. Where the domain requires uniqueness or scoping, enforce it in application code or a scoped reorder endpoint rather than relying on the field.

Sequencing. (1) Confirm Nova version and package constraints against the exact stack. (2) Run a staging POC on one resource with sample records. (3) Test drag reorder, reload persistence, pagination, filters, permissions, soft deletes, and concurrent edits. (4) Add the DB index, an audit or backup strategy, and a documented manual fallback for ordering. (5) Roll out to one or two low-risk resources. (6) Assign explicit ownership for future Nova upgrades — including the decision to fork — and monitor. Parallel track: record the Nova-vs-Filament-vs-custom-admin platform question this feeds into, so the package is evidence in that conversation rather than an accidental commitment.

Operational Impact

Maintenance. Low upstream activity and a 2022 release mean the team owns compatibility outright. Budget recurring effort at each Nova upgrade: dependency and security scans, Composer constraint review, asset publishing, and a smoke test of reorder persistence. The codebase is small enough that a fork is manageable, but a fork still needs an owner, test coverage, and a slot in the upgrade checklist. Frame the maintenance cost honestly as small but permanent — this is not a set-and-forget dependency.

Support. No vendor SLA, limited community support, a single maintainer. Provide internal documentation covering what the field does, the order-column convention, the backfill procedure, the known-issues list, and the manual fallback for reordering if the UI breaks. Avoid making it a dependency of revenue-critical admin workflows unless a fallback path exists and is documented. Treat a broken upgrade path as a UI regression to be triaged rather than an incident — but only once the spike has verified that assumption.

Scaling. Acceptable at admin scale: bounded lists, human-speed interaction, tens to low hundreds of rows per resource, a handful of concurrent editors. It is not designed for high-frequency programmatic reordering, large bulk imports, or lists where order changes are a transactionally significant business event. Where ordering drives customer-facing merchandising at volume, keep the authoritative reorder logic in application services and treat the Nova field as one client of that logic, not the source of truth. Also watch scope creep: once editors can reorder, adjacent requests (schedule this, publish that, order per store) will arrive, and the package will not absorb them.

Failure modes. Enumerate them explicitly in the risk register so triage is fast: Nova upgrade breaks asset compatibility (UI regression, ordering still readable but not draggable); reorder endpoint fails silently and the UI displays an unpersisted order (worst case, needs verification); concurrent editors overwrite each other with no locking (last-write-wins, tolerable at small team size but worth stating); temporary duplicate order values violate a unique constraint (avoid the constraint); filtered or paginated drags produce a globally wrong sequence (test explicitly); and drag-and-drop is inaccessible by keyboard (provide a numeric fallback or accept the gap with eyes open). Every one of these is a bounded admin annoyance rather than data loss — but that must be verified in the spike, not asserted.

Ramp-up. Effectively zero for developers (Composer install, one field registration) and near-zero for editors (drag and drop is self-evident, which is the entire point). The real ramp-up cost is organisational: getting the dependency registered in the inventory as unmaintained-but-tolerated with a named owner, adding it to the Nova upgrade checklist, and documenting the fallback. That is half a day of process work that prevents a future surprise, and it should be scheduled as part of adoption rather than discovered during the next Nova upgrade.