- What does ncus/inline-index actually do in a Laravel Nova application?
- It is a Laravel Nova custom field that lets an operator edit an ordering or position column directly from a resource index table, instead of opening each record's detail form. That makes it an admin-productivity shortcut for nudging rows on curated lists, typically ten to fifty entries. It runs only inside the Nova admin surface, so it has no role in public APIs, customer-facing UI, or domain workflows.
- How do I install and register this Nova inline index field?
- Installation is Composer plus a single field registration inside the target resource's fields() method. Run the Nova asset publish step afterwards, since unpublished compiled assets are the most common cause of a field that installs cleanly but renders blank. Before running composer require, confirm the Composer identity matches the repository you intend to use, because the registry description and the repo name describe different packages.
- Why doesn't the Composer name ncus/inline-index match the repository name laravel-nova-inlineIndex?
- The registry entry describes a schema helper for declaring inline database indexes on Eloquent models, while the repository and its documentation describe a Nova ordering field. Those are two different packages, so the identity must be reconciled against composer.json, src/, and resources/js/ before anyone installs it. Installing the wrong one silently gives you a helper class that no Nova resource can reference.
- Which Laravel, PHP, and Nova versions does this field support?
- Supported versions are not clearly documented, so check the version constraints in composer.json before committing. Nova custom fields bind to Nova internals and compiled Vue assets, so the critical check is whether the constraint is capped below your current Nova major. Pin the package and verify it against your exact Laravel, PHP, and Nova combination in a staging branch first.
- Does the field save on blur, on Enter, or through a separate action?
- The save trigger is not documented and should be treated as an open behavioral unknown. Blur, Enter, and an explicit action button all produce very different operator workflows and different risks of accidental writes. Test each interaction on a non-critical Nova resource before rolling the field out to a team.
- Does inline editing go through Nova's standard update endpoint and inherit policies and validation?
- This is unconfirmed and matters because inline editing is a write path, not a display change. If writes pass through Nova's standard update endpoint, they inherit your policies and validation rules automatically; a bespoke endpoint would bypass both. Confirm the persistence path in the source before enabling the field anywhere that authorization matters.
- Does the inline index field support readonly() and validation rules()?
- Support for readonly() and rules() is not documented, so validate it yourself if either is required. Readonly matters when some operators should see the position column but not change it, and rules matter if position values are constrained to a range or must be unique. Where support is missing, gate the field with Nova authorization instead.
- Does it automatically re-sequence sibling rows or prevent duplicate sort values?
- No. Nothing in the package re-sequences siblings, so editing a position can leave duplicate or sparse integers in your ordering column. That data-quality liability sits entirely with the adopting team, and it becomes visible as unstable list ordering once duplicates exist. Plan a periodic re-sequence job or a uniqueness constraint scoped to the parent record if ordering accuracy matters.
- How does it behave on large paginated indexes and alongside defaultSort() and sortable()?
- Behavior on large paginated indexes and its interaction with defaultSort() and sortable() are unverified. Inline position editing is designed for short curated lists, so expect friction when the index spans many pages or is sorted by the same column being edited. Test with production-like data volumes before assuming the ordering stays visually stable after a save.
- Is it production-ready, what license and test coverage does it have, and can I fork it into app/Nova/Fields?
- Adoption signals are thin: a small star count, no dependents, and no visible maintenance cadence, so adopting it makes you the de facto maintainer. License terms and test coverage are not established in the documentation and should be confirmed before shipping. Forking into app/Nova/Fields and vendoring the Vue component is a reasonable hedge, but budget time for namespace friction and keep a native read-only field in place as a documented fallback and rollback path.