mindy/orm-fields
Mindy ORM Fields is a Laravel package for adding flexible custom fields to Eloquent models. Define reusable field types, store dynamic attributes, and manage model metadata without changing your core database schema.
mindy/orm-fields is an add-on collection of extra field types for the MindyPHP ORM. It is not a standalone ORM; it presupposes a MindyPHP application and its core mindy/orm data-mapper. The package surfaces the usual field concerns — typed accessors, casting, serialization, and possibly validation hooks — as composable field classes rather than ad-hoc model attributes.
Architecture fit. Fit is narrow by design. The package only makes sense if the surrounding application already runs on MindyPHP and uses its ORM conventions (field registration, mapping metadata, hydration pipeline). For a Laravel codebase — our default stack — this is a foreign object. Laravel's Eloquent has its own cast system ($casts, custom casts, accessor/mutator conventions, attribute casting to value objects), and mindy/orm-fields does not plug into that contract without an adapter layer that we would own and maintain.
Integration feasibility. The technical work is not installing the package; it is reconciling two ORM philosophies. Realistic effort sits in: (a) confirming the field base class/interface contract and whether fields are registered globally or per-model; (b) mapping Mindy field semantics onto Eloquent casts or, if the app is genuinely Mindy, onto its model metadata; (c) bridging any persistence assumptions (column types, nullability, serialized payload formats) that differ from Laravel migrations. The package's surface area looks small, which is favorable, but there is no meaningful corpus of public usage to validate the happy path.
Technical risk. High, and mostly non-technical in origin. One star, zero dependents, and no downstream consumers mean no field-tested integration path, no community answers, and no failure reports to learn from. The MIT license is permissive and low-risk legally. The material risks are: bus-factor (likely a single maintainer or abandoned), undocumented coupling to a specific MindyPHP version, and the probability that a bug we hit is one we must fix ourselves. Because the field layer touches persistence, defects manifest as corrupt or mis-typed data rather than crashes — the more expensive failure mode.
Key questions.
Stack fit. Poor-to-conditional for a Laravel-first organization. Adopt only inside a MindyPHP application; do not adopt as a general-purpose field library. If the target system is Laravel, the correct move is almost always to implement the equivalent as Eloquent custom casts — a few dozen lines each, fully under our control, with no third-party dependency and no cross-framework impedance.
Migration path. Two realistic scenarios. Greenfield Mindy app: add the package at project bootstrap, pin an exact version, and wrap its field registration in a thin internal module so that our models import from our namespace rather than the vendor namespace. That indirection makes a future replacement a one-file change. Laravel app or mixed stack: do not port the package. Instead, inventory the field behaviors it provides, then reimplement the ones we actually need as Eloquent casts and value objects. This is a small, bounded piece of work and eliminates the dependency entirely.
Compatibility. Verify against our PHP runtime (8.x) and the exact MindyPHP release in use. Because the package has no dependents, assume compatibility is asserted rather than proven — treat the declared constraints as a hypothesis and confirm with a smoke test covering CRUD plus hydration of every field type we intend to use.
Sequencing.
Maintenance. This is the dominant cost. With a single star and no dependents, we should assume we are the de facto maintainers. Budget for periodic source audits at each PHP and MindyPHP upgrade, and for owning patches. The MIT license at least permits forking, but forking is a commitment, not a solution — factor it in as a real outcome, not a contingency.
Support. Effectively zero external support. No Stack Overflow footprint, no issue history of consequence, no vendor SLA. Internal documentation of the field contract and our wrapper becomes mandatory, because knowledge will otherwise live with whichever engineer ran the spike.
Scaling. The package is a field layer, so horizontal scaling is not its concern; persistence and query behavior are the ORM's. Risk emerges if fields introduce per-hydration overhead or serialized payloads that inflate row size — worth measuring once at representative row counts before committing to high-volume tables. Our scale here is likely tens of thousands of rows, not billions, so this is a benchmark-and-move-on item, not an architecture blocker.
Failure modes. Three to watch: silent schema drift (a field's column type diverges from the ORM's expectation after an upgrade), hydration exceptions on legacy rows whose payload predates a field change, and abandonment — the package stops receiving updates while our runtime moves on. Mitigations are ordinary: integration tests on the field layer, a migration path for stored payloads, and the internal wrapper to make substitution cheap.
Ramp-up. Low in absolute terms — the package is small and the wrapper is thin — but the learning cost is front-loaded on MindyPHP itself, not on this package. A Laravel-fluent engineer needs onboarding to Mindy's ORM conventions before field usage is safe. Estimate one engineer-week for spike plus wrapper plus tests, assuming prior MindyPHP familiarity; roughly double that without it.
Recommendation. Treat this as a tactical, tightly-scoped dependency inside a MindyPHP application, pinned and wrapped, with a documented reimplementation path. For any Laravel-centric system, decline and implement the required field behaviors as native Eloquent casts — the signal here (1 star, 0 dependents) does not justify the coupling.
How can I help you explore Laravel packages today?