Sexy Field Doctrine Laravel Package

Product Decisions This Supports

• Custom-field / dynamic-attribute roadmap bets. This package is the Doctrine-ORM bridge for dionsnoeijen/sexy-field, a flexible field system (typed, validated custom fields attached to models, stored EAV-style). It exists to answer a single product question: can we offer user-defined fields on top of our domain entities without migrating to Eloquent? That is directly relevant to CRM, project management, forms, and any multi-tenant SaaS where customers configure their own schema.
• Build vs. buy for the "flexible fields" capability. Rather than deciding in the abstract, this package lets you evaluate a buy-side option at near-zero cost — it's MIT, one composer require away, and small enough to read end-to-end in an afternoon. That makes it a cheap spike candidate before committing engineering time to a bespoke EAV or JSON-column design.
• ORM architecture decision (Doctrine vs. Eloquent). Because it only matters if you're running Doctrine inside Laravel, adopting it is effectively a statement that your domain layer is Doctrine-centric (common in DDD-heavy or legacy-symfony-influenced shops). It should inform — not drive — that architectural conversation.
• Prioritization and risk triage. With 0 stars, 0 dependents, a single maintainer, and a score of ~1.0, the decision this package most reliably supports is "do not put this on the critical path." It's a useful input to a "spike, don't standardize" call.

When to Consider This Package

Consider it only when all of the following hold:

• You are already running Doctrine ORM inside a Laravel application (not just Laravel's default Eloquent), and you have a concrete, near-term need for user-defined custom fields on those entities.
• You are already using sexy-field on the Eloquent side and want parity for Doctrine entities — otherwise you're adopting two unmaintained dependencies to solve one problem.
• You treat it as a throwaway evaluation spike with a defined timebox (days, not sprints), and your team can read and patch the source if needed.
• Your PHP/Laravel/Doctrine version constraints happen to align with whatever the package pins — verify before promising anything.

Look elsewhere when any of these are true:

• You're on standard Laravel/Eloquent. This package adds nothing; the Doctrine bridge is dead weight.
• You need production-grade reliability. Zero dependents means zero field validation. No evidence of CI, no community, no security response process, single point of failure on the maintainer.
• A simpler primitive solves it. JSON/JSONB columns with typed casts, spatie/laravel-schemaless-attributes, Doctrine json types, or embeddables cover most "custom fields" needs with first-party support and far lower TCO.
• Schema flexibility is core to your product. If custom fields are a headline feature, own the abstraction — EAV query performance, indexing, and validation semantics are product decisions you don't want outsourced to an unmaintained bridge.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed integration package with no adoption — no stars, no downstream users, one maintainer. It is not a dependency to standardize on, but it is a free, low-cost probe into whether we should build flexible custom fields into our product. Recommendation: fund a short, timeboxed spike that reads this package and its parent, validates the EAV approach against our actual query patterns, and returns a build-vs-buy recommendation — with a default bias toward native JSON columns or an in-house typed-field layer. Risk of skipping it: near zero. Cost of adopting it blindly: an unmaintained dependency in our domain layer.

To engineering: Treat tardigrades/sexy-field-doctrine as reference material, not a dependency. It shows one workable shape for attaching typed, validated custom fields to Doctrine entities in Laravel. Read it, benchmark the storage model, then decide: (a) fork and own it, (b) implement the pattern natively on Doctrine JSON/embeddable types, or (c) drop Doctrine-specific flexibility entirely. Whatever we choose, we should be able to articulate why EAV beats JSONB (or vice versa) for our query and indexing profile — the package itself doesn't answer that for us.