- How do I install outl1ne/nova-color-field in Laravel Nova?
- Install it with composer require outl1ne/nova-color-field. The package is a single Nova field subclass plus a compiled Vue component, and Laravel package discovery registers it automatically, so there is no service provider to wire and usually no config to publish. After that, add a nullable string column to the model and a Color::make(...) line to the Nova resource's fields method. Budget a half-day spike including staging verification rather than a full sprint.
- Which color formats does this Nova color field support?
- It stores and edits colors as a string and supports hex, rgb and rgba output formats. You can enable an optional alpha channel when transparency is needed. Most teams keep hex as the stored format for simplicity and choose the format that matches how the value will be consumed downstream. Because the value is a plain string, whichever format you pick should match the validation and normalization you enforce server-side.
- Does the field support an alpha channel for transparent colors?
- Yes, alpha channel support is optional and produces rgba-style values when enabled. Turn it on only for attributes where transparency is genuinely meaningful, since downstream consumers such as CSS variables, PDFs and emails must handle rgba reliably. If you enable it, make sure your server-side validation regex accepts the alpha form, because the picker itself is not a guarantee of format.
- What database column type should I use for a Nova color field?
- Use a nullable string column, for example $table->string('brand_color')->nullable(). Avoid char(7), because you will want blank values and you will hit 3-digit hex during prototyping. Keep one hex string per attribute: a palette means three columns and three fields, not a JSON blob. For existing free-text color columns, plan a data-hygiene pass to normalize case, expand 3-digit hex and convert empty strings to null.
- Can I customize the picker palette and preset swatches?
- The package supports a customizable picker palette and preset swatches, so editors choose from brand-approved colors instead of arbitrary ones. Presets are a UI convenience, not an enforcement mechanism: a request that never touched the picker can still post any string. If governed palettes matter to your product, add a server-side allowlist check alongside the field.
- Which Laravel Nova versions does nova-color-field work with, and does it support Vite?
- This is a Laravel Nova field and has no value outside a licensed Nova instance, so confirm your Nova major first. Verify compatibility against your exact Nova version in staging rather than trusting composer.json, and note whether your app runs Nova on Vite or the legacy Mix pipeline. Nova field packages ship compiled JavaScript, so a Nova upgrade can break the component while CI stays green. Treat compatibility as an explicit upgrade-checklist item.
- Does the color field render on Nova index and detail views?
- Yes, it works across Nova's index, detail and form views, and swatches render cleanly in forms and detail views. It is a form control only: it owns no routes, migrations, queues or background jobs. Index and detail views display the stored string, so legacy values like uppercase hex, 3-digit hex or empty strings will appear exactly as saved. Normalizing data on write keeps those views consistent.
- Should I validate the hex value server-side if the picker already enforces it?
- Yes. The picker's hex-only behavior is a client-side promise, and any request that never touched the picker can post anything. Add hex validation in a FormRequest or model observer, normalize the value (lowercase, strip stray hashes, expand 3-digit hex) and decide explicitly whether blank means null. The field is a convenience, never the sole guarantee of format.
- Is outl1ne/nova-color-field actively maintained and safe for production?
- It is MIT licensed with a thin footprint: roughly two dozen GitHub stars, no listed dependents and a single maintainer. That is limited evidence of production hardening, so you would be an early adopter and the one to notice a break first. It is a reasonable fit for an internal admin swatch and a weaker fit for a customer-facing surface. If that risk profile is unacceptable, a plain text input with a hex regex or a small in-house Vue component is the alternative.
- How do I remove the color field later or fall back to a plain text input?
- Exit cost is low: remove the Color::make line from the resource, and the column plus its data stay intact, still readable through a plain text field with a hex regex. There is no migration to unwind because the field owns no schema of its own. Document who owns the fork-and-own fallback before it is needed, and keep your validation rules in place so the stored data survives the switch.