Nova Grid Laravel Package

Getting Started

This package extends Laravel Nova by letting you control the rendered width/size of form and detail inputs — useful when Nova's default full-width fields make dense resources (settings pages, address blocks, meta panels) hard to scan. Version 1.0.0 is an initial release, so treat the API as early and pin the version in composer.json until you've validated it against your Nova major version.

Minimal steps:

1. composer require <vendor>/<package> — confirm the constraint supports your Nova version (Nova 4 vs 5 asset pipelines differ; a 1.0.0 package may target only one).
2. Publish anything the service provider exposes: php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" (expect a config file and possibly compiled assets under public/vendor/...).
3. Rebuild/publish Nova assets if required: php artisan nova:publish (and npm run dev/prod if the package ships uncompiled JS).
4. Look first at the published config (usually config/nova-*.php) for global default sizing and at src/ for the field class you'll actually use in fields().

First use case: take a single Text field on a resource form and render it at half width, then confirm the same field is sized correctly on the detail view. That single loop — form, detail, validation error state — tells you whether the package's wrapper approach fits your resources.

Implementation Patterns

Per-field sizing in fields(). The core workflow is chaining a sizing method onto the field before returning it, e.g. Text::make('Phone')->width('50%') or ->resize('md') depending on the exposed API. Keep these chains in fields() and fieldsForDetail() deliberately — many Nova sizing packages apply to the form only unless you opt the detail view in.

Centralize widths. Rather than scattering magic strings across dozens of resources, define constants or a small enum (FieldWidth::HALF, FieldWidth::THIRD) and use them consistently. This makes a later global re-layout a one-file change instead of a grep across app/Nova.

Compose with Nova's layout primitives. Sizing pairs best with Panel, Field::make(...)->stacked(), or the Flex/row helpers. If your Nova version groups fields, size the group rather than each child, otherwise you get nested width conflicts.

Base resource / trait. For resources that share a common shape (SEO blocks, audit fields, address sections), put the sized field definitions in a trait or abstract resource and merge() them in. This is the day-to-day win: consistent layout without copy-paste, and one place to fix when the package's API changes.

Config-driven defaults for legacy resources. Apply a global default via config so existing resources look reasonable immediately, then override per field where the default is wrong. Prefer this over touching every resource on day one.

Responsive intent. Nova's admin is used on laptops and wide monitors. Favor percentages or the package's breakpoint-aware options over hard pixel widths, and test at ~1280px where Nova's sidebar plus a Panel column gets tight.

Gotchas and Tips

• Asset publishing is the #1 failure mode. After install and after every package update, re-run nova:publish and hard-refresh. A stale public/vendor bundle makes it look like the methods do nothing. Same applies to php artisan optimize:clear on cached deployments.
• Width applies to the wrapper, not the input. If a field still looks full-width, the inner component may set w-full. Inspect the DOM (Form Field → wrapper → input) before assuming the package is broken, and add a small CSS override if a third-party field ignores the wrapper.
• Third-party fields are the weak point. nova- packages that ship their own Vue components may not honor the wrapper sizing. Budget time to verify each custom field type you rely on; the built-in Text/Select/Textarea are the safe path.
• Detail views differ from forms. Nova renders detail rows with different markup and sometimes a label/value grid. If a field is sized correctly on edit but not on detail, it's almost always a missing detail-view flag rather than a bug — check the package's config or method docs.
• Validation errors and help text. Narrow fields push error messages and help() text into awkward wrapping. Always test a failing validation state on a 1/3-width field; you may need to keep narrow fields to short labels.
• Percentages vs Nova's grid classes. Nova already applies width utilities in some layouts. Stacking a package width on top of Nova's classes can produce a field that silently snaps to a different size — one source of truth per field.
• Debugging checklist: confirm the provider is auto-discovered (php artisan about / vendor/composer/installed.json), confirm config is published and cached config cleared (config:clear), confirm assets published, then inspect the emitted class/style on the wrapper.
• Extension points to prefer: published config for defaults, published views/components if you need markup changes, and a thin CSS file for overrides. Avoid editing vendor/ — a 1.0.0 package will move fast, and local patches will be lost on the next composer update.
• Pin and watch. At 1.0.0 there is no deprecation history, so use "^1.0" cautiously in a team setting; lock the exact version in composer.lock, note the package in your upgrade checklist, and re-verify layouts after any Nova major upgrade since the rendering internals it hooks into are the most likely thing to break.