Eav Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, and the brief mislabels the stack. msgphp/eav-bundle is a Symfony bundle, not a Laravel package. It ships a Bundle subclass wired through Symfony's kernel, DI container and DoctrineBundle conventions, and it sits on top of a family of first-party packages (msgphp/eav domain, msgphp/doctrine-bridge, msgphp/domain, msgphp/user). It assumes: Doctrine ORM entities and mapping, Symfony service tagging/compiler passes, and the msgphp DDD/messaging idioms (commands, events, repositories). None of that maps onto Laravel's Eloquent-first, service-provider-driven container without a rewrite. The EAV domain model is the only genuinely reusable asset here — and it is small enough to reimplement.

Integration feasibility — effectively zero for a Laravel codebase. Realistic paths and why each fails:

Technical risk — high, dominated by abandonment, not code quality.

• 0 stars, 0 dependents, and an ecosystem (msgphp/*) that is dormant. No security triage, no PHP/Symfony/Doctrine version bumps, no issue response.
• Dependency ceiling: expect constraints pinned to PHP ~7.x and Symfony 4/5-era and Doctrine ORM 2.x. Laravel 10/11 baselines (PHP 8.2+, and modern Doctrine if used) sit outside the tested matrix; transitive conflicts are likely and unpatchable without forking.
• MIT license is clean — forking is legally fine, but you inherit maintenance of a multi-package graph.
• The opportunity: 9.65 score is an artifact of the unmet-need signal (EAV is a recurring requirement), not evidence of package viability. Weight score: 0.03, stars and dependents far more heavily.

Key questions to resolve before any commitment:

1. Is the requirement truly dynamic (tenant/admin-defined attributes discovered at runtime), or just "we'd rather not write migrations"? The latter is solved by JSON columns; the former needs a real EAV or document model.
2. Query patterns: do users need to filter, sort, facet or aggregate on attribute values? This single answer determines whether EAV tables, JSON + functional/GIN indexes, or an external search index (Meilisearch/Typesense/Elasticsearch) is the right shape.
3. Cardinality: entities × attributes × values per tenant. Order-of-magnitude changes the design (thousands of rows vs. hundreds of millions).
4. Typing and validation: who defines attribute types, are they mutable after data exists, and what happens to existing values when an attribute is retyped or deleted?
5. Multi-tenancy and i18n: per-tenant attribute definitions and per-locale values are common EAV requirements and are not free.
6. Is anyone on the team fluent in Symfony/msgphp? If no, the reference-design value drops further.

Recommendation: do not adopt. Treat the repo as a design reference for the EAV domain (attribute / value / type separation, repository boundaries) and build the capability natively in Laravel.

Integration Approach

Stack fit. The target stack is Laravel + Eloquent (+ optionally a search service). The bundle's fit is Symfony + Doctrine. There is no supported bridge. The pragmatic Laravel-native options, in order of preference:

1. Promoted columns + JSON long tail (hybrid). Keep hot, indexed attributes as real columns; store the long tail in a json/jsonb column with generated columns or functional indexes for the handful of attributes that must be filtered. Lowest operational cost, best query planner behaviour, weakest for unbounded attribute counts.
2. Classic EAV tables (attributes, attribute_values with entity_type, entity_id, attribute_id, typed value columns or JSON value). Best for genuinely runtime-defined schemas and admin UIs; worst for query complexity and performance at scale.
3. Document store / search index as the read model. Normalised write model in MySQL/Postgres, denormalised attribute document in Meilisearch/Typesense for faceted filtering. Correct answer when attribute-based search is the primary use case.

Pick (1) unless requirement #1 and #2 above both point to runtime-defined schemas with faceted search — then (3) with (2) as the write model.

Migration path. There is no incremental adoption path from this package, so sequencing is entirely greenfield:

• No data migration from the bundle (nothing runs today). If EAV data already exists in some form, that's a separate extraction/backfill exercise.
• Reuse: copy the domain vocabulary (Attribute, AttributeValue, type system, value coercion rules) into Laravel value objects; discard all Symfony/Doctrine plumbing.
• If Doctrine is already present in the Laravel app for legacy reasons, scope the new EAV work to Eloquent to avoid widening the dual-ORM surface.

Compatibility. Verify early and explicitly: target PHP version, Laravel major, database engine and version (MySQL 8.0.13+ for functional indexes; Postgres 12+ for jsonb GIN and generated columns). The bundle's constraints will almost certainly conflict with any of these; a composer require attempt is a 15-minute spike that will confirm the dead end and should be timeboxed to exactly that.

Sequencing (suggested, ~4–6 eng-weeks end to end):

1. Week 0 — spike (2–3 days). Attempt install in a throwaway Laravel app to document the failure; simultaneously prototype the top 10 real queries against JSON-column and EAV-table schemas with representative data volumes. Output: schema decision memo.
2. Week 1–2 — domain layer. Attribute definition model, type system, validation, value coercion, repository interfaces. Unit-tested in isolation; no framework coupling.
3. Week 2–3 — persistence + indexing. Eloquent implementation, index strategy, query builder/scope API for attribute filtering, pagination and eager-loading to avoid N+1.
4. Week 4 — admin surface. CRUD for attribute definitions, type-change and delete semantics, tenant scoping, audit trail. This is where most EAV projects actually fail; budget for it.
5. Week 5 — read model / search integration if required, plus backfill tooling and a rollout flag.
6. Week 6 — performance validation at 10× expected volume; document the query patterns that are not supported.

Operational Impact

Maintenance. You own 100% of it from day one — there is no upstream. That is a feature (no surprise breaking changes, no abandoned transitive deps) but it means EAV becomes a small internal product with a named owner, a test suite, and a documented query API. Budget ~10–15% of one engineer ongoing, plus the admin UI which will attract continuous feature requests from whoever manages attributes.

Support. No vendor, no community, no security advisories. If a CVE lands in a transitive dependency of the bundle, there will be no patched release — the mitigation is not depending on it. This alone disqualifies it for anything with a compliance or long-horizon support obligation.

Scaling. EAV's cost profile is the main operational hazard:

• Value tables grow as entities × attributes × locales. A 100k-entity catalogue with 50 attributes and 3 locales is ~15M rows before any history/versioning.
• Attribute-filtered list pages become multi-join or GROUP BY/HAVING puzzles; the query planner degrades non-linearly as attribute count rises. This is the failure mode that usually forces a migration to a search index 18 months in.
• Unbounded, admin-created attribute definitions mean index churn and unpredictable cardinality — cap attribute counts per entity type and enforce it in the product, not just the schema.
• Cache/denormalisation: attribute values are read on nearly every page; plan for caching the resolved attribute set per entity, with invalidation keyed on attribute-definition changes as well as entity changes (the second is easy to forget and causes stale-schema bugs).

Failure modes to design against:

• Type drift — retyping or deleting an attribute orphans or corrupts existing values. Needs explicit migration semantics and a dry-run/impact preview.
• Missing vs. null — "attribute not set" and "attribute set to null/empty" are different; conflating them breaks filtering and reporting permanently.
• Orphaned values on entity delete; require cascading cleanup or soft-delete-aware joins.
• Inconsistent validation between the admin surface and the API write path.
• Index bloat — over-indexing every attribute on day one; index lazily, driven by observed query patterns.
• N+1 storms in list views; mandate eager-loading in the repository API rather than leaving it to callers.

Ramp-up. For the team: low framework risk (the rebuilt version is plain Laravel), but a real conceptual curve on EAV modelling, type systems and the query API. Half a day of design documentation plus the week-0 spike memo is sufficient onboarding. For a Symfony/msgphp-fluent engineer the bundle's idioms would be familiar, but that expertise buys little here since the plan is to rebuild rather than adopt — its only value is a shorter design phase on the domain layer.

Bottom line for the roadmap: the unmet need (opportunity: 9.65) is real and recurring; this package is not the vehicle for it. Fund a 1-week spike to choose between JSON-hybrid and EAV-table schemas, then build the domain natively in Laravel. Estimated total: 4–6 engineer-weeks plus ongoing ~15% FTE ownership.