Eav Bundle Laravel Package

Product Decisions This Supports

• Custom fields / user-defined attributes. EAV (Entity-Attribute-Value) is the canonical data model for letting admins or customers add fields to an object without a migration each time. This package is a reference implementation of that pattern: attribute definitions per entity class, typed values, and a persistence layer wired into the ORM.
• Roadmap prioritisation for "configurable data" features. If your backlog includes custom fields on contacts, products, tickets, or assets — a near-universal B2B SaaS request — this is evidence the demand is real and that the modelling problem is well understood. Treat it as a design input for that epic, not as a shipped dependency.
• Build vs. buy. The honest answer here is build, informed by this code. The package is archived, last released January 2016, has 10 stars and zero dependents. Buying/adopting means inheriting unmaintained code; reading it costs a day and de-risks a multi-week build.
• Vendor/stack fit check. Despite being catalogued as a PHP package, this is a Symfony bundle built on Doctrine ORM, not a Laravel package. In a Laravel/Eloquent codebase it is not installable in any practical sense — adopting it means a port. That decision (port vs. in-house vs. library) is the one this evaluation actually informs.
• Use cases worth scoping: multi-tenant schemas where each tenant defines its own fields; CMS-style metadata on content types; product catalogues with variable attribute sets (size, colour, material); compliance/CRM records where field sets differ per region or segment.
• Alternative evaluation set to put on the same decision doc: native JSON/JSONB columns (Laravel json casts, Postgres jsonb + GIN indexes), a purpose-built maintained custom-fields package for Laravel, or a document store. EAV is one point on that spectrum, and usually not the first one to reach for.

When to Consider This Package

Consider the pattern (via this code as reference) when:

• Attributes are genuinely open-ended and defined at runtime by users, not by your team.
• The number of distinct entity types with custom fields is more than one or two, so a shared attribute/value schema beats a bespoke table per type.
• Writes are relatively infrequent compared to reads of a known attribute set — EAV read paths are workable when you can eager-load a fixed list of attributes.
• You need per-tenant field definitions and per-tenant validation, i18n labels, and ordering — the metadata overhead is the actual product value.
• You want to mine MIT-licensed code for entity/attribute/value schema shape, typed value handling, and admin CRUD ergonomics before writing your own.

Look elsewhere — do not adopt this package — when:

• You are on Laravel. It is a Symfony/Doctrine bundle; there is no bridge. This alone is disqualifying.
• You need a maintained dependency. Archived, no releases since 2016, no dependents means no downstream pressure to fix anything. No PHP 8 compatibility, no security response, no upstream support. Any CVE or PHP-version break is yours to fix forever.
• Your queries are analytical. EAV forces multi-join pivots for filtering, sorting, and aggregation. Reporting, BI, exports, and "filter by three custom fields and sort by a fourth" get slow and ugly fast. If the feature is report-heavy, prefer JSONB with indexes or a document store.
• You need database-level constraints. EAV columns are typically VARCHAR/TEXT with type info in a metadata row, so FKs, uniqueness, and type safety live in application code. That is a real, permanent maintenance tax.
• A simpler model fits. If "custom fields" really means 5–15 optional columns known at design time, nullable columns or a JSON column are cheaper, faster, and far easier to query. Do not pay EAV's complexity for a bounded problem.
• Volume is high and hot. Row-per-attribute explodes row counts and join depth; validate with a realistic dataset before committing.

How to Pitch It (Stakeholders)

To executives — one paragraph: "Custom fields" is one of our most requested capabilities, and this package shows the standard way to model it. It is not something we should install: it was last released in 2016, is officially archived, and has no users depending on it — and it's built for Symfony, not our Laravel stack. The good news is it's MIT-licensed, so we can read it freely. My recommendation is a short spike to extract the schema design, then build a thin internal custom-fields layer on our own stack, most likely on JSON columns with a metadata table. That keeps us off a dead dependency while still delivering the feature. Cost is a contained piece of work inside the existing epic; the licence and the age of the code mean no procurement or legal work is needed.

To engineering — the summary:

• Verified: Symfony bundle, Doctrine ORM, MIT, archived, last release 2016-01-13, 10 stars, 0 dependents. Not installable on Laravel.
• Value is the schema pattern (entity → attribute definition → typed value), not the code. Budget roughly a day to read it for schema shape and admin UX before we design.
• Recommended target: attributes metadata table (entity type, key, type, required, validation, ordering, tenant scope) plus values in a JSON column on the entity, with generated/functional indexes for the filterable subset. This avoids the row-explosion and join-depth problems that make pure EAV painful to query and report on.
• Named risks to design against up front: query/filter performance, reporting and export paths, type safety and validation living in app code, and per-tenant index strategy.
• Decision requested: approve the spike and the build-in-house direction; explicitly rule out adopting opifer/eav-bundle as a dependency.