Colour Laravel Package

Product Decisions This Supports

• Feature scoping for any user-supplied colour input. Theme editors, brand-kit settings, CMS page builders, product variant swatches, avatar/background pickers, chart series config, and email-template designers all need the same underlying question answered: "is this string a valid colour?" This package turns that into a single, declarative validation rule instead of hand-rolled regex scattered across form requests.
• Build vs. buy (and the honest answer: "buy, but wrap it"). The capability is ~50 lines of regex for hex-only. The package's value is breadth — multiple notations (hex, rgb()/rgba(), hsl(), CSS named colours) and consistent error messaging — so the decision is really "do we want to own multi-format colour grammar?" For most teams the answer is no.
• Roadmap input for input-hardening and accessibility work. If your roadmap includes WCAG-driven contrast checks or "accept a colour from any design tool" (Figma gives hex, rgb, and sometimes hsl), this is the validation layer that unblocks the parser/converter work behind it. It is an enabler, not a differentiator — the 0.38 opportunity score reflects that colour validation is a commodity capability with no competitive moat.
• Data-quality decisions downstream. Consistent validation at the boundary means your colour columns, CSS injection points, and design-token exports don't accumulate junk values that break theme rendering later. Cheap to add now, expensive to backfill.
• Prioritisation signal. Do not put this on a roadmap as a feature. Treat it as infrastructure debt paid in one afternoon during whatever ticket first needs colour input, and size it as such.

When to Consider This Package

Adopt when:

• You're on a maintained Laravel/PHP stack and already accept Composer dependencies for validation concerns (e.g. you use laravel-validation-rules/* siblings or similar micro-packages).
• You accept colour input from end users or external integrations, where formats vary and you cannot control the client.
• You need multiple colour notations validated in one place, with messages you can localise.
• You want the validation declared in FormRequests / Validator::make rather than embedded in controllers or frontend-only checks (frontend validation is a UX affordance, not a security boundary — server-side validation still matters).
• You value a permissive licence (Apache-2.0) for commercial or redistributed products.

Look elsewhere — or just write a regex — when:

• You only ever accept one canonical format (e.g. #RRGGBB from a colour picker you control). A four-line regex is cheaper than a dependency, its CVE feed, and its upgrade path.
• You need semantic colour work rather than syntactic validation: contrast ratio / WCAG compliance, colour-space conversion, palette generation, delta-E distance. This package validates; it does not compute. Pair it with a conversion library or expect to build that layer.
• Dependency hygiene is a hard constraint (regulated environments, minimal-dependency policy). At 33 stars and a last release of Feb 2023, this is a low-traffic single-maintainer package. Mitigate by wrapping it behind your own App\Rules\Colour so replacing it later is a one-file change — or vendor the logic outright; it's small enough to own.
• Your Laravel/PHP version has moved past what the package declares support for. Check composer.json constraints before committing; an unmaintained constraint can block your framework upgrade, which is a far bigger cost than the feature is worth.

How to Pitch It (Stakeholders)

For executives (30 seconds): "Users can currently type arbitrary text into colour fields, which produces broken themes, support tickets, and occasionally malformed CSS. There's an existing, permissively licensed (Apache-2.0) open-source component that solves this for Laravel. Cost is roughly half a day of integration plus near-zero ongoing cost. It is not a differentiator — competitors solve this trivially — but it closes a data-quality gap and removes a class of bug. Risk is low and bounded: it's small, isolated, and we'll wrap it so we can swap or replace it in an hour if it's ever abandoned."

For engineering: "Adds a Colour validation rule usable directly in FormRequests. Handles hex, rgb()/rgba(), hsl() and named colours so we stop maintaining bespoke regex per feature. Apache-2.0, so no licence review friction. Caveats: low activity (33 stars, last release Feb 2023) and it validates only — no contrast checking, no conversion. Two asks: (1) confirm the illuminate/validation and PHP constraints match our floor before we adopt; (2) wrap it in App\Rules\Colour so the dependency never leaks into feature code and we can fork the body if upstream goes quiet. If the wrapper feels like more work than the rule itself, that's a signal to just write the rule."

Framing to avoid: don't sell this as a capability or a moat. It's plumbing. The pitch is reduced surface area for bad data at negligible cost, with the maintenance question answered up front rather than discovered in eighteen months.