sunel/eav
Sunel/EAV brings flexible Entity-Attribute-Value modeling to Laravel. Attach dynamic attributes to Eloquent models without constant migrations, store typed values, and query entities by custom attributes—ideal for catalogs, CMS data, and configurable products.
Architecture fit. sunel/eav implements the Entity–Attribute–Value pattern as a first-class Laravel construct: a small set of polymorphic tables (entities, attributes, values) plus an Eloquent trait that lets any model carry runtime-defined attributes, with Artisan generators scaffolding the entity types, attributes, migrations, and seeders. That is a good architectural match when a meaningful share of the domain schema is genuinely unknown at build time and driven by admins or tenants — product catalogs with per-category fields, CMS content types, per-tenant custom fields, configurable forms. It is a poor match when the majority of fields are known upfront, when reporting and aggregation dominate, or when the product needs strong relational integrity and indexed sorting/filtering across many attributes simultaneously. The EAV pattern trades schema flexibility for query complexity, weak typing, and a value table that grows in rows rather than columns; the package does not change that fundamental trade-off, it only makes it idiomatic to Laravel.
Integration feasibility. Mechanically straightforward: it is a Composer package with a service provider, publishable migrations/config, and eav:* Artisan commands. A developer can stand up an entity type and attach attributes in an afternoon. The friction is entirely version-related. The last release (2018-09-03) targets the Laravel 5.5–5.7 / PHP 7.1–7.3 era; it predates Laravel 6's semver shift, the Symfony 4/5 upgrades, PHP 7.4/8.x typing changes, and the removal of several legacy helpers. Dropping it into a Laravel 9/10/11 application is likely to require a fork and patches before the first migration runs. Treat it as source code to adopt, not a dependency to install.
Technical risk. Three risks dominate. First, abandonment: a single-maintainer package with 153 stars and no release in six-plus years means no upstream security or compatibility patches; your team becomes the maintainer by default. Second, framework drift: every Laravel major upgrade becomes a fork-and-patch exercise with no upstream safety net, and the package's tests (if any) were written against a runtime you no longer use. Third, EAV-intrinsic risk: filtering or sorting on multiple attribute values requires self-joins or post-query filtering, N+1 queries are easy to introduce through the trait's accessors, and the value table has no database-level type enforcement, so bad data is silent until it surfaces in a report. The low opportunity score (3.02) is consistent with this — the capability is real, but the package is not where new opportunity is being created in 2024-era Laravel, where JSON columns and jsonb/generated-column indexing cover much of the same ground with better tooling.
Key questions.
Stack fit. Native fit is Laravel 5.5–5.7 with PHP 7.1–7.3 on MySQL or PostgreSQL; SQLite works for tests. In that environment it is a low-friction install: composer require, publish, migrate, generate. In a modern stack (Laravel 9+/PHP 8.2+) assume fork work: pin illuminate/* constraints, replace removed helpers, resolve type-hint and return-type incompatibilities, and re-run the suite under the target PHP version. Budget one to two sprints for the fork before feature work begins, and validate that the trait coexists with global scopes, soft deletes, and any existing model observers.
Migration path. For a greenfield Laravel 5.x app, adopt directly. For anything newer, mirror the repository into a private VCS package, tag it, and treat it as internal code — this preserves the option to patch without blocking on upstream. In parallel, prototype the same use case with JSON columns (json on MySQL 5.7+, jsonb with GIN indexes on PostgreSQL) and Laravel's native casting. The comparison should be driven by the actual query patterns, not by feature checklists: JSON wins on simplicity and indexing for moderate attribute counts, EAV wins when attribute definitions are dynamic and metadata-driven validation, lists, and per-attribute configuration are required. Be honest about which of those you need.
Compatibility. Verify the published migrations against your DB engine and charset settings, confirm index coverage on the values table (entity lookup and attribute lookup are different access paths and both need indexes), and check whether attribute definitions are cached or re-queried per request — if not cached, add a metadata cache early. Confirm how attribute types are validated; if validation is thin, wrap writes in a form-request or service layer derived from attribute definitions.
Sequencing. (1) Two-week spike on a single entity type covering create/read/update/delete, multi-attribute filtering, and a load test at projected volume. (2) Data-model and query-pattern review against the JSON alternative. (3) Decision gate: adopt, fork-and-adopt, or replace. (4) If adopting: metadata caching layer, validation/service layer, and API/admin UI. (5) Performance benchmark at target cardinality before committing other teams to the schema.
Maintenance. The dominant ongoing cost is ownership. With no upstream releases since 2018, your team absorbs framework upgrades, PHP version bumps, security review, and bug fixes. Each Laravel major becomes a planned maintenance item rather than a routine Composer update. Estimate a partial FTE during the first year for the fork, caching, and validation layers, tapering to a smaller but permanent allocation for upgrade cycles. This cost is the main thing to weigh against the build effort of a JSON-column or bespoke attribute system.
Support. Community-only. A 153-star package with a stale release means GitHub issues may go unanswered and Stack Overflow coverage is thin. There is no vendor to escalate to, no SLA, and no security advisory channel you can rely on. Mitigate with an internal runbook, a named owner, and a pinned fork you control.
Scaling. The values table grows by rows, not columns, so it scales acceptably for read-by-entity workloads and degrades for reporting, multi-attribute filtering, and bulk export. Add composite indexes on entity and attribute access paths, cache attribute definitions aggressively, and be prepared to materialize denormalized read models or search indexes (e.g., a search engine) if filtering requirements grow. Writes are multi-row and should be wrapped in transactions; concurrent attribute edits on the same entity need a locking or optimistic-concurrency story.
Failure modes. Expect: orphaned values after entity or attribute deletion (check for cascade behavior); type mismatches written silently into a generic value column; N+1 storms from trait accessors on collections; stale attribute metadata after admin changes if caching is added without invalidation; and upgrade breakage at each Laravel major. Monitor for query-count regressions on entity list endpoints and for value-row growth outpacing entity growth.
Ramp-up. The EAV concept is learnable in a day for a competent Laravel developer, but the package's conventions are documented mainly through its README and generated code, so onboarding means reading source. Plan for internal documentation of the entity/attribute lifecycle, the generator workflow, and the query patterns that are and are not supported. Developers who have only worked with conventional relational models will underestimate the filtering and reporting constraints; make those explicit in the architecture notes before the team builds on the schema.
How can I help you explore Laravel packages today?