Colour Laravel Package

Product Decisions This Supports

• Build vs. buy for colour math. Colour conversion, palette derivation, mixing/blending, and contrast-ratio computation are well-understood, deterministic algorithms with no product differentiation. This package lets you buy that logic instead of owning it, freeing engineering capacity for surface-level features.
• Accessibility / compliance roadmap. Contrast-ratio and luminance calculations underpin WCAG AA/AAA checks. If your roadmap includes accessibility commitments, a colour library is the lowest-cost way to validate user-chosen or brand-defined colours before they ship.
• Theming and branding features. Brand-colour ingestion, dark-mode palette derivation, and tenant-specific theming are classic "needs a colour library" features. This supports decisions on whether to ship self-serve theming, per-tenant branding, or admin-configurable palettes.
• Scope discipline. If your product needs only hex↔RGB conversion in one or two places, this reinforces the "don't add a dependency" decision. If it needs lightness adjustment, alpha compositing, and contrast scoring across several surfaces, it reinforces adoption.
• Platform lifecycle planning. Release 5.2.0 drops PHP 8.4 support. That turns an otherwise invisible dependency choice into a runtime-matrix decision: teams must either stay pinned to 5.1.0 or plan their PHP upgrade path around the package's supported range.

When to Consider This Package

Adopt when most of the following hold:

• You need real colour manipulation (conversions, mixing, lightness/saturation adjustment, contrast scoring) across more than one feature area.
• Your application runs on a PHP version inside the package's supported range — verify this first. With 5.2.0 dropping PHP 8.4, any fleet standardised on 8.4 must pin 5.1.0 or defer the upgrade.
• You are willing to wrap it behind an internal ColourService/adapter interface so the vendor type can be swapped later.
• You accept a single-maintainer dependency for non-critical presentation logic.

Look elsewhere when:

• PHP 8.4 is your baseline or near-term target. Pinning to 5.1.0 means you inherit an unmaintained branch; patch and security backports are unlikely for a package of this size.
• You expect Laravel-native ergonomics. This is a framework-agnostic PHP package with no service provider, facade, config publishing, or Blade helpers — you will write that glue yourself.
• You need image-level work (resizing, tinting uploaded assets, format conversion). That is an image-processing concern, not a colour-value concern.
• Your need is trivial (one hex→RGB helper). Twenty lines of code is cheaper than a dependency and its version constraints.
• You require vendor SLAs, multi-maintainer bus factor, or a documented deprecation policy.

How to Pitch It (Stakeholders)

For executives: This is a small, focused library that handles colour calculations — the maths behind brand theming, dark-mode palettes, and accessibility contrast checks. It removes a recurring "we'll just write it ourselves" tax from our design-system and accessibility work. Cost is negligible; the real consideration is risk, not price. It is maintained by a single author and its newest release narrows PHP compatibility rather than widening it, so it should be treated as a convenience dependency, never a load-bearing one. Recommendation: adopt behind a thin internal wrapper, pin the version deliberately, and revisit if it blocks a platform upgrade.

For engineering: Framework-agnostic, pure-PHP value objects — no Laravel coupling, no global state, easy to unit test and easy to wrap behind an interface. The 5.2.0 release is effectively a compatibility change: it drops PHP 8.4, so composer resolution will fail for 8.4 environments and those projects must stay on 5.1.0. Before adopting, confirm the supported PHP range against our runtime matrix, decide explicitly whether we pin 5.1.0 or 5.2.0, and record that decision — do not let it float. Our integration surface should be a single adapter class so a future swap is a one-file change.