Nova Row Laravel Package

Product Decisions This Supports

• Admin form density (UX ROI): This package lets you place Nova form fields side-by-side in a row instead of the default vertical stack. It directly supports decisions like “can we cut the scroll depth of our biggest resource forms in half before the next ops review?” — a cheap, visible win for internal users (support, ops, sales admin) who live in Nova daily.
• Roadmap scoping for the admin panel: Use it as a data point in the “how much do we invest in Nova customization?” conversation. If layout polish is a recurring complaint, the answer is either (a) upgrade to Nova 4+, where Row/Stack field containers are native, or (b) accept a small third-party shim on Nova 3. This package makes the “buy/borrow” option concrete and near-zero cost.
• Build vs. buy vs. native: The honest decision here is “native, if possible.” Since Nova 4 ships row/stack containers, this package’s reason to exist is confined to Nova 3.x estates. It supports a decision to not build a bespoke row field, and to not maintain one.
• Migration sequencing: It helps justify an upgrade ticket (“move to Nova 4 and drop this dependency”) rather than a customization ticket (“write our own layout field”). That is a meaningful product decision about where engineering time goes.
• Legacy triage: If this appears in an audit of composer.json dependencies, it is evidence of a Nova 3 codebase and a small, contained piece of technical debt — useful for scoping an upgrade, not a reason to panic.

When to Consider This Package

Consider it only when all of the following hold:

• You are pinned to Laravel Nova 3.x and cannot upgrade in the current cycle.
• You have a specific, high-traffic resource form where vertical field stacking is genuinely hurting usability (e.g., address blocks, name pairs, date ranges, money + currency).
• You are willing to vendor or fork the code, given the repository is archived and has ~17 stars.
• The layout need is simple and non-responsive-critical: fixed side-by-side columns, no advanced breakpoint behavior.

Look elsewhere — or do nothing — when:

• You are on Nova 4+: use the built-in field containers. Adding this package would be redundant dependency risk with zero upside.
• You need actively maintained dependencies, security patching, or vendor support. Archived status is a hard stop for anything customer-facing.
• You need complex or responsive layouts, multi-column grids, tabs, or nested repeaters — evaluate purpose-built Nova layout packages or a custom field instead.
• The pain is actually information architecture (too many fields, unclear grouping) rather than spacing. Reordering and pruning fields, or splitting into separate resources/tabs, is the higher-leverage fix.
• Your team has no appetite to own a fork; the maintenance burden, however small, outlives the benefit.

How to Pitch It (Stakeholders)

For executives: This is a tiny, free layout add-on for our admin panel that makes dense forms easier to scan — think city/state/ZIP on one line instead of three. It is a quick usability improvement with no licensing cost. The important caveat: the project is archived and effectively unmaintained, so we should treat it as a stopgap, not a foundation, and fold its function into our planned Nova upgrade rather than building a dependency on it. Recommended position: do not adopt for new work; use it only as a short-lived patch on Nova 3, or skip it entirely if the upgrade is within a quarter or two.

For engineering: It is a thin Nova field wrapper that composes child fields into a single row. Two viable paths: (1) if we are on Nova 4, use the native Row container and close this out; (2) if we are stuck on Nova 3 and the form pain is real, vendor the source into our codebase (a few files) rather than pulling 64robots/nova-row from Packagist, so we control compatibility and are not exposed to an abandoned package. Either way, add a line to the Nova upgrade checklist to remove it afterward. Effort: hours, not days. Risk: low technically, moderate on dependency hygiene — which is exactly why we fork rather than require.