Eav Laravel Package

Product Decisions This Supports

• Build vs. buy for dynamic attributes. Decides whether your product stores arbitrary, user-defined fields (custom product specs, CRM contact fields, CMS content types) using a prebuilt EAV layer or a bespoke schema. Adopting sunel/eav is effectively "buy the pattern, own the code" — it saves maybe 2–4 weeks of schema/validation scaffolding but adds a dependency you will likely fork.
• Feature scoping for "custom fields" requests. Sales and support will ask for per-tenant or per-category fields. EAV is the classic answer; this package gives you entity types, attribute definitions, typed values, and validation out of the box, which lets you size that roadmap item concretely instead of hand-waving.
• Data model standardization across modules. If catalogs, CMS pages, and CRM records all need extensible attributes, one EAV abstraction (rather than three bespoke JSON columns) is a genuine architectural simplification — and a decision worth making once, at the platform level, not per feature.
• Prototype/spike decisions. At 153 stars and a last release of 2018-09-03, this is a candidate for a time-boxed spike, not a load-bearing dependency. The decision it supports is "do we validate the EAV UX with a throwaway build, or commit to a maintained alternative?"
• Technical debt and migration planning. Because the package targets the Laravel 5.x/6 era, evaluating it forces an explicit answer to "what is our supported Laravel range, and who owns third-party maintenance?" That answer affects hiring, upgrade cadence, and sunset planning.
• Low opportunity score (3.02) as a market signal. A modest star count and a stale release suggest limited community momentum. That argues for treating EAV as an internal capability rather than a differentiator, and for not betting roadmap commitments on this package's longevity.

When to Consider This Package

Consider it when:

• You are on (or pinned to) Laravel 5.5–6.x and cannot or will not upgrade in the near term.
• You need genuinely multi-entity EAV — several entity types sharing one attribute system — rather than one table with a few optional columns.
• You want typed attributes with validation and admin-facing definitions without writing the entity/attribute/value tables, repositories, and casting layer yourself.
• The team is small and a 2–4 week head start on scaffolding is worth more than long-term upstream support.
• Attribute counts and read volume are moderate — admin panels, back-office tooling, internal CMS/CRM — where query complexity is tolerable.
• You are explicitly evaluating EAV as a pattern and want a working reference implementation to critique.

Look elsewhere when:

• You need current Laravel (10/11/12) support, PHP 8.2+, or an actively maintained dependency. Unmaintained since September 2018 is the headline risk.
• Read paths are hot and reports require heavy filtering/sorting/aggregation across attributes — EAV pivots and multi-joins will hurt, and a reporting/denormalized layer becomes mandatory.
• Your real need is schemaless flexibility on a single model, which JSON columns (spatie/laravel-schemaless-attributes, or native Postgres JSONB) solve with far less complexity and better query ergonomics.
• You require first-class search, faceting, or filtering at scale — an external index or a dedicated product-information system is the right layer.
• Nobody on the team can own a fork. Committing to a stale package without a maintenance owner is how you get a frozen upgrade path.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost option for one specific problem — letting customers define their own fields without us shipping a database migration every time. It is not a strategic platform bet. The package has modest adoption (153 stars) and has not been released since September 2018, so I'm recommending we use it, if at all, to validate the feature quickly and budget for replacing or owning it. Expect a modest time saving up front and an ongoing maintenance line item; the alternative — native JSON columns plus our own validation — is more work now but materially less risk.

To engineering: It gives us entity types, typed attribute definitions, value storage, and validation on top of Eloquent, which is roughly the scaffolding we'd otherwise write by hand. The catch is that it predates modern Laravel and PHP, so treat it as a starting point, not a library we depend on: fork it, pin it, and write our own acceptance tests around attribute CRUD, casting, and query performance before it touches a production schema. If we're on Laravel 10+, the honest comparison is JSON/JSONB columns or a maintained schemaless package, and I'd like that decision made explicitly rather than by default.