Eav Bundle Laravel Package

Product Decisions This Supports

• Custom-fields feature scoping. The package encodes the EAV pattern as first-class domain objects (attribute definitions, typed values, assignment to entities). Evaluating it forces the team to answer the roadmap question "do we ship tenant-defined custom fields this quarter?" with a concrete data model rather than a vague backlog item.
• Build vs. buy vs. borrow. It is a small, MIT-licensed reference implementation, not a platform. The realistic decision it informs is borrow: read the domain model, adopt its vocabulary (attribute, value type, entity assignment), and write your own persistence layer — rather than buy (no vendor, no support) or build from zero (duplicated design work).
• Schema strategy trade-off. Choosing EAV over a JSON/JSONB column or dedicated per-tenant tables has long-tail consequences for reporting, indexing, and validation. This package makes the EAV side of that trade-off cheap to prototype, so the decision can be made on evidence (query shapes, migration cost) instead of opinion.
• Multi-tenant and vertical expansion. The clearest use cases are: per-tenant custom attributes in a SaaS product, catalog attributes for products with heterogeneous schemas, CRM/records metadata, and integration mapping tables where partner payloads carry arbitrary keys.
• Deferral / kill decisions. Because the package is domain-only (it does not provide Doctrine mapping, migrations, or query building), a spike will quickly reveal the true cost center — persistence and querying, not modeling. That is a useful input for deciding whether custom fields are a Q3 deliverable or a Q4 one.

When to Consider This Package

Consider it only when all of the following hold:

• Your stack is Symfony with msgphp/domain and msgphp/entity already in use. Despite being described as a Laravel/PHP package, this is a Symfony bundle wired into the msgphp framework's aggregate/identity conventions. On Laravel it is not a dependency you install — it is a design document you read and re-implement.
• You need an EAV domain model as a starting reference and are prepared to own the code: fork it, vendor it, assign a maintainer, and accept responsibility for PHP version bumps and security review.
• Attribute reads are point lookups on a single entity, not cross-entity analytics. EAV punishes you at reporting time, and this package does nothing to soften that.
• You can tolerate zero community signal: 0 stars, 0 dependents, no issue activity. Treat it as sample code with an MIT header, not as a supported library.

Look elsewhere — or write it yourself — when:

• You are Laravel-native. Use JSON columns plus a validation/schema layer, or an existing schemaless-attributes package. Porting Symfony bundle conventions into Laravel's container and Eloquent is more work than the model is worth.
• You need query performance, filtering, or sorting on attribute values at any scale; EAV plus no persistence layer means you are building the hard part anyway.
• You require maintenance guarantees: security advisories, framework version support, or an upgrade path. There is no evidence any of that exists here.
• You need typed value validation, i18n, versioning, or per-attribute indexing out of the box. The description says "basic," and basic is what you should expect.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, MIT-licensed design reference for "custom fields," a feature customers increasingly ask for. It is not a strategic purchase or a vendor relationship — there is no company behind it, no support contract, and no adoption by other projects. Recommendation: fund a one-to-two-week spike to prototype custom fields against this model, with the explicit expectation that we will write and own the persistence and query layers ourselves. Do not let it into production as an unowned dependency.

To engineering: It gives you a clean, opinionated EAV domain model — attribute definitions, typed values, entity assignment — that saves design debate and gives us shared vocabulary with the msgphp ecosystem. It gives you almost nothing else: no ORM mapping, no migrations, no query builder, no tests you can rely on, and it is a Symfony bundle coupled to msgphp/domain, so on our Laravel codebase it is source material, not a package. Treat it as a fork-and-own starting point with a named maintainer, or as a 200-line design crib that we reimplement idiomatically in a few days. The spike will tell us which is cheaper; my prior is the latter.