Colour Laravel Package

Technical Evaluation

innmind/colour is a framework-agnostic PHP colour-manipulation library (immutable value objects for RGB/HSL/HSV conversion and comparison). It ships no Laravel service provider, facade, config file, or migrations — it is a plain Composer dependency, not a Laravel package. That makes architecture fit straightforward: it slots into the domain/service layer like any other pure-PHP library, with no coupling to the framework's container or lifecycle.

Integration feasibility is high in principle — a single composer require — but this release materially changes the platform contract. 5.2.0 drops PHP 8.4 support. Because 5.2.0 is a minor version bump, consumers reasonably expect backward compatibility; a reduction in supported runtime is a breaking change in practice even if it is not signalled as one. The likely mechanisms are either an accidental narrowing of the composer.json PHP constraint (e.g. >=8.1 permitting 8.4 implicitly) or an upstream incompatibility the maintainer chose to exclude rather than fix.

Technical risk is therefore concentrated in dependency resolution, not in runtime behaviour. Composer will fail to resolve on PHP 8.4 hosts, or — worse — silently select 5.1.x, creating version drift across environments. Secondary risks: single-maintainer project with a small ecosystem footprint and no formal LTS commitment.

Key questions:

• Which PHP versions exist across our dev, CI, staging, and production fleets, and is 8.4 present anywhere?
• Was 8.4 support previously explicit and working in 5.1.0, or only implicitly permitted?
• What is the actual failure on 8.4 (deprecation noise, type error, transitive dependency), and is reinstatement on the roadmap?
• Is the PHP constraint in composer.json an upper-bounded range, or an open >= that lets Composer attempt 8.4 anyway?
• Is this library already a transitive dependency of something else we run?

Integration Approach

Stack fit. Compatible with Laravel at any version whose PHP floor is ≤ 8.3. It is a value-object library, so the idiomatic integration point is a custom Eloquent cast (persist colours as hex/string columns, hydrate to value objects) plus hand-written validation rules. Do not expect Laravel-native ergonomics — no published config, no container bindings, no Artisan tooling.

Migration path. Two viable routes, decided by the runtime inventory:

1. On PHP ≤ 8.3 everywhere — adopt 5.2.0 directly and pin it. No data migration, no schema change, no rewrite of call sites.
2. On PHP 8.4 anywhere — hold at 5.1.x with an explicit ceiling, or pin 5.2.0 and cap the runtime at 8.3. Do not allow an unpinned range that lets Composer resolve differently per environment.

Compatibility. Treat this as a platform-level breaking change despite the minor version. Enforce composer.lock in VCS for applications, and for any shared internal library add "php": ">=8.1 <8.4" alongside "innmind/colour": "^5.2" so the constraint fails loudly at install time rather than silently degrading to 5.1.

Sequencing.

1. Inventory PHP versions across all environments and CI images.
2. Audit whether innmind/colour is a direct or transitive dependency.
3. Confirm with the maintainer the reason for dropping 8.4 and any reinstatement timeline.
4. Add a CI matrix job covering the lowest and highest supported PHP versions.
5. Pin and adopt; document the 8.3 ceiling in the dependency policy if route 2 applies.

Operational Impact

Maintenance. Low ongoing surface area — no configuration, no migrations, no runtime services. The real maintenance cost is constraint hygiene: someone must own the PHP version ceiling and revisit it when 8.4 support returns or when we are forced onto 8.4 by a framework upgrade.

Support. Community-only, effectively single-maintainer, no commercial backing and no support SLA. Acceptable for a utility library of this scope; unacceptable as a critical path without a fork-or-replace contingency.

Scaling. Negligible. Pure CPU-bound value transformations with no I/O, no state, no external services. Cost scales with call volume in request handling only, and only for colour-heavy code paths.

Failure modes.

• Deploy-time resolution failure — a host upgraded to PHP 8.4 breaks composer install. Highest-probability failure; mitigate with locked dependencies and an explicit PHP ceiling.
• Silent downgrade — Composer resolves 5.1.x on 8.4 hosts and 5.2.0 elsewhere, producing divergent behaviour between environments with no error.
• Cross-environment drift — developer laptops on 8.4, production on 8.3, CI on neither.
• Serialization surprises — value objects leaking into JSON responses or queue payloads if the Eloquent cast is incomplete.
• Abandonment — no release for an extended period while our PHP floor moves past the supported range.

Ramp-up. Low for engineers comfortable with immutable value objects and custom casts; moderate for those expecting a Laravel-idiomatic API with facades and config. Budget a short internal note covering the PHP ceiling, the cast pattern, and the pinning policy — the version constraint is the detail most likely to be missed and the one most likely to cause an incident.