Statamic Color Swatches Laravel Package

Product Decisions This Supports

• Design-token enforcement in the CMS. This fieldtype replaces free-form color entry with a named, editor-approved palette ({ label, value[] }), which is a governance decision as much as a UI one: it makes "brand colors only" enforceable at the content layer instead of in a style guide nobody reads.
• Build vs. buy for a narrow fieldtype. The surface area is roughly one PHP fieldtype, two Vue 2 components, a gradient helper, and a GraphQL bridge. The realistic comparison is not "buy vs. build from scratch" but "adopt vs. spend half a sprint reimplementing," and that decision should be made on maintenance appetite, not capability.
• Headless / API roadmap. GraphQL registration means swatch selections are queryable from a decoupled frontend, so this can support a headless Statamic rollout without a custom resolver. Worth flagging if your roadmap includes an API-first content surface.
• Multi-value color use cases. Because value accepts an array of CSS strings and renders a linear-gradient, this supports gradients, duotone accents, and layered backgrounds — not just flat brand colors. That widens the use cases to hero backgrounds, category badges, and chart series without needing a second fieldtype.
• Editor UX / content velocity. Clickable swatches remove a class of support tickets ("what's the hex for our blue?") and reduce invalid CSS reaching production. This is a measurable reduction in content QA cycles if your team currently pastes hex codes.
• Standardization across sites. If your organization runs multiple Statamic properties, a shared, versioned addon is cheaper than N bespoke fieldtype forks, provided you accept the dependency.

When to Consider This Package

Consider adopting when:

• You are on Statamic v6 / PHP 8+ and already use the CP for content entry — this is a native addon, not an integration.
• Editors must choose only from a fixed palette, and you want that constraint expressed in field configuration rather than editorial policy.
• You need gradient or multi-stop color values, which the built-in color fieldtype does not express cleanly.
• You have a headless/GraphQL consumer and want swatch values available without a custom type.
• You are comfortable with small-vendor risk and can vendor or fork the code if needed. With 15 stars, 0 dependents, and a single maintainer, this is a code you should be prepared to own.
• Your frontend team can consume { label, value[] } — the stored shape is simple enough to map into design tokens or CSS custom properties at render time.

Look elsewhere or build in-house when:

• You need arbitrary color picking — Statamic's built-in color fieldtype is the right tool; this addon intentionally restricts choice.
• You require vendor SLAs, security review, or test coverage. There are no PHPUnit tests, no static analysis, and no CI gates in the repo; the dist/ build is committed, which means auditing the shipped JS is a manual exercise.
• You are not on Statamic, or are pinned to an older Statamic major — the addon targets v6 and Vue 2 components via the CP runtime.
• You need localized labels or dynamic palettes driven by an external design system API; configuration is static field config.
• Your team has no Vue 2 / Statamic CP experience and no appetite to maintain a fork if the maintainer goes quiet.
• Accessibility for the swatch UI is a hard requirement — the component is clickable swatches with CSS background styling; color-only affordances typically need a paired label and keyboard/contrast review that you would own.

How to Pitch It (Stakeholders)

To executives: This is a small, free, open-source addon that constrains color choices in our CMS to an approved brand palette. The business outcome is brand consistency and fewer content QA cycles — editors pick from a curated list instead of pasting hex codes, so off-brand colors stop reaching production. Cost is near zero to adopt; the honest caveat is that it is a low-traffic community package with a single maintainer, so we should treat it as code we're willing to own rather than a supported vendor product.

To engineering: A Statamic v6 fieldtype addon with a well-bounded surface: one fieldtype class, a GraphQL type, two Vue 2 CP components registered through Statamic.$components, and a Vite build committed to dist/. Config defines named swatches; values are stored as { label, value: string[] }, with process() normalizing comma-separated strings into arrays and GraphQL resolving to the first color. Integration is a Composer require and a fieldset config entry. Risks are explicit and manageable: no test suite or static analysis, committed build artifacts, Vue 2 dependency inherited from the Statamic CP, and a bus factor of one. Recommend a timeboxed spike, vendor the package into our lockfile, and add a smoke test in our own suite covering field config → stored shape → GraphQL output so we detect breakage on Statamic upgrades.

To design/content ops: Editors get a row of clickable swatches with human-readable names, defined once in the fieldset, and multi-stop swatches render as gradients so accent and hero treatments are supported. The constraint is the feature — the palette becomes the single source of truth, and changing a brand color is a config change rather than a content audit.