Laravel Polymorphic Eav Laravel Package

Product Decisions This Supports

• Feature scoping for "custom fields" requests. This package is a ready-made pattern for the recurring ask: "Can we let customers/admins define their own attributes on records without us shipping a migration each time?" It gives you a concrete cost estimate (one polymorphic attributes table vs. per-tenant schema work) for that roadmap item.
• Build vs. buy for extensible data models. The package is small (MIT, single-purpose, ~one relation trait). That makes the real decision "vendor/fork ~a few hundred lines" rather than "adopt a dependency," which is a cheaper and more defensible call than committing to a heavyweight EAV or custom-fields platform.
• Data model strategy: EAV vs. JSON columns vs. relational. Useful as the reference implementation when deciding how to store sparse, variable metadata. EAV buys you per-attribute rows (indexable, queryable one attribute at a time); JSON columns buy simpler writes and worse filtering. This package lets you prototype the EAV side quickly and compare against Laravel's native json casts before committing.
• Use cases it maps to: per-tenant custom fields on core entities (customers, projects, tickets), product catalog attributes that vary by category, CMS/content metadata, integration field mapping (storing third-party payload fields), and internal admin-configurable labels.
• Multi-entity extensibility without N tables. The polymorphic side means one attribute store serves many models — a genuine scope reduction versus building a bespoke customer_attributes, product_attributes, ticket_attributes set.
• Non-goal clarification. Adopting an EAV store is also a decision to not support first-class filtering, sorting, and aggregation on those fields in v1. Making that trade-off explicit early prevents a roadmap surprise when someone asks for "filter the list by any custom field."

When to Consider This Package

Adopt or prototype with it when all of the following hold:

• You need arbitrary, user-defined attributes attached to more than one Eloquent model, and a per-model table per entity is clearly wasteful.
• The dominant access pattern is read-and-display (show a record's attributes on a detail page), with light single-attribute filtering at most.
• You're pre-product-market-fit or building an internal tool where time-to-schema-change matters more than query performance or data integrity guarantees.
• Your team is comfortable vendoring the code — copying the trait and migration into your app and owning it — rather than pulling it as a maintained dependency.
• You're on a Laravel version the package actually runs on; verify this yourself before anything else, since the last release was August 2021.

Look elsewhere — or build it yourself — when:

• Maintenance risk is unacceptable. Six stars, zero dependents, and no release since 2021 is not a track record; there's no evidence of production hardening, no community to answer questions, and Laravel 10/11 + PHP 8.2+ compatibility is unverified. For anything on a multi-year support horizon, treat this as sample code, not a dependency.
• Reporting or analytics matter. EAV makes "group by region, sum revenue" painful; if attributes feed dashboards, cohorts, or exports, use a relational or JSON-plus-generated-columns design instead.
• You need to filter, sort, or paginate efficiently across multiple attributes. Attribute values land in a generic column, so you lose type safety and per-attribute indexes unless you add them.
• Data volume is large or query counts are watched. Polymorphic attribute loading is an N+1 magnet; eager loading helps but the join shape is awkward for complex queries.
• You need typed validation, units, or enums per attribute. This package stores values; the attribute definitions layer (types, required-ness, allowed options) is on you.
• A first-party or well-maintained alternative fits. Laravel's native json column casting, or a maintained schemaless-attributes package, often covers the same need with better support — and if the requirement is truly fixed, plain relational columns still win.

How to Pitch It (Stakeholders)

To executives: There's a recurring class of request — "let us define our own fields" — that normally costs us a schema migration per customer. This package demonstrates a single flexible attribute store that serves every entity at once. It's MIT-licensed and small enough to own outright, so the downside is capped: worst case we spend a short spike and keep the pattern. The caveat is real, though — the project has minimal adoption and hasn't shipped since 2021 — so I'd recommend we treat it as a reference design to fork, not a dependency to lean on, and only for features where flexible fields genuinely unblock a deal or an experiment.

To engineering: This is a polymorphic attributeable relation plus a trait — roughly the implementation we'd write ourselves in an afternoon. Recommendation: time-box a one-day spike, vendor the trait and migration into our codebase, add attribute definitions (type, validation, options) that the package doesn't provide, and confirm Laravel/PHP compatibility before writing it into any plan. Explicitly out of scope for v1: filtering, sorting, and aggregating across custom fields — if that requirement appears, we revisit with a relational or JSON approach rather than extending the EAV store.

Bottom line: High learning value, low strategic risk if treated as a forkable pattern; medium-to-high risk if adopted as a maintained third-party dependency. Use it to de-risk the "custom fields" roadmap item, not to anchor a platform bet.