Values Laravel Package

Product Decisions This Supports

• Configuration and settings modeling. Wrapping config arrays in a Value object gives typed, read-only, dot-path access and reduces the classic bug class where a key is missing or nested differently across environments.
• Read-only view models / DTOs. Sits between raw request/API arrays and domain logic, giving object ergonomics without adopting a full DTO framework.
• Lazy / deferred evaluation. Useful for computed configuration, environment-dependent defaults, or expensive values that should not resolve unless actually read.
• Refactor safety. Consumers depend on $value->foo rather than $array['foo']['bar'], so the internal shape can change behind the object.
• Build vs. buy. This is a small, single-purpose utility. Adopting it is cheap if the pattern fits; if it doesn't, Laravel's built-in data_get() plus a small internal helper or PHP 8.1 readonly classes cover most of the same ground.
• Roadmap framing. Helps answer whether "object views over arrays" should become a codebase convention — and if so, whether to standardize on this package or on a maintained alternative.

When to Consider This Package

Consider it if:

• You are already in the Enqueue / FormaPro family and want consistency across that ecosystem.
• You specifically need the combination of array/object dual access, dot-path reads, and lazily computed values.
• The team is willing to vendor or pin a small, MIT-licensed dependency it may have to fork later.

Look elsewhere — strongly — if:

• Maintenance matters. Last release is March 2019. There are no guarantees for PHP 8.1/8.2+; verify compatibility on your target runtime before anything else.
• Community support matters. ~30 stars means no meaningful ecosystem, no Stack Overflow base, and no security disclosure process you can rely on.
• You only need dot-notation reads: Laravel's Arr::get / data_get is already there.
• You need real value objects, casting, or validation: spatie/laravel-data, webmozart/assert, or native readonly classes and enums are better supported.
• You are touching a security- or compliance-sensitive path: unmaintained code is a supply-chain liability.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed utility that makes array data safer to consume by presenting it as an object. It is cheap to trial but effectively unmaintained — last release in 2019 with negligible adoption. The real decision is not "is it good?" but "are we prepared to own it?" Recommendation: treat it as a reference pattern rather than a dependency unless a specific niche (lazy computed configuration) justifies pinning it and, if necessary, forking it.

To engineering: The idea is sound — object ergonomics over arrays, with laziness and path access — but you will be on your own for PHP 8+ compatibility, bug fixes, and security patches. Preferred alternatives: built-in data_get() for reads, native readonly DTOs (8.1+) or spatie/laravel-data for structured values, and a thin internal Value helper if you want the lazy/dot-path behavior. If adopted, hide it behind a small adapter interface so call sites survive a swap.