Laravel Json Meta Laravel Package

Product Decisions This Supports

• JSON metadata vs. first-class schema — the recurring build decision for "custom fields," per-tenant settings, integration configs, and third-party payloads. This package lowers the cost of the JSON-column option by enforcing a typed contract at the model boundary, which makes the trade-off (flexibility vs. queryability) a real comparison rather than a default.
• Use cases it makes cheaper to say yes to: customer-defined attributes (product catalog extras, CRM record fields), per-tenant feature/config blobs, stored webhook/provider payloads, experiment and flag configuration, form-builder submissions — anywhere the shape changes on a product cadence but you still want bad data to fail loudly instead of silently.
• Build vs. buy vs. vendor: with MIT licensing, a small surface area, and only ~10 stars plus an archived status, the realistic decision is not "adopt a dependency" but "use as a reference implementation or vendor the code." That is a support-cost and ownership decision, not a feature decision.
• Roadmap sequencing: if more than two or three models are trending toward ad-hoc JSON casts, this is the trigger to decide on a shared metadata layer now — before each team hand-rolls its own cast and the shapes drift.
• Risk register / on-call: archiving means no CVE response and no Laravel-version compatibility work. That converts a technical choice into a staffing commitment (someone owns the fork), which belongs in planning, not just in a ticket.

When to Consider This Package

Adopt (as a vendored/forked internal dependency) when:

• You are on the Laravel/PHP versions its single 2024-05 release targets, and you accept that you will bump it yourself for future framework upgrades.
• You have a small, single-team codebase where metadata shapes ship alongside app deploys — no need for runtime schema migration.
• Strictness is the actual pain: you want unknown keys rejected, types enforced, and nested structures hydrated into objects rather than raw arrays.
• Someone will own it: vendor it into the repo, pin it, wrap it behind your own base cast/interface so it is swappable, and add tests around hydration failures.

Look elsewhere when:

• You need to query or index metadata keys at scale (Postgres GIN, MySQL generated columns) — a JSON-column abstraction does not solve filtering performance.
• You need audit trails, schema migrations for metadata, or compliance-grade validation — build on a dedicated attributes/EAV table or a JSON Schema validator (opis/json-schema, justinrainbow/json-schema) instead.
• You expect long-term OSS support, security patching, or a large team unfamiliar with the package.
• The scope is one model with three keys: Laravel's native array / AsArrayObject cast plus a small DTO is less code than the dependency.

Evaluate against: native casts + spatie/laravel-data DTOs, spatie/laravel-schemaless-attributes, and a hand-rolled strict cast (~1–2 days of work).

How to Pitch It (Stakeholders)

For executives: This is a small, cheap evaluation, not a strategic bet. The package gives Eloquent models strongly typed metadata in JSON columns, which would let us ship customer-defined fields and integration configs without a migration per change. However, it is archived, has negligible adoption, and gets no security or framework-compatibility updates — so the recommendation is a timeboxed spike (1–2 days) to compare it against a hand-rolled typed cast, not a production dependency. Worst case we borrow the pattern; the cost of reversing either path is low.

For engineering: It is a cast-layer abstraction — strict key/type enforcement over a JSON column, hydrated into typed objects, so bad metadata fails at the boundary instead of in a report three weeks later. Because it is MIT and archived, treat it as reference code: fork or vendor it, pin the version, hide it behind our own interface, and own the Laravel upgrade path. Budget the spike to answer two questions — does the strictness model match our failure-handling conventions, and does the hydration cost hold up on our largest metadata payloads. If either answer is no, a native cast plus DTO covers the same ground.