Laravel Meta Laravel Package

Product Decisions This Supports

• Custom fields / configurable attributes without schema churn. This package attaches arbitrary key–value metadata to any Eloquent model through a single polymorphic table. That directly supports roadmap items like "let admins add custom fields to products/customers/orders" without shipping a migration for every new attribute.
• Build vs. buy for extensibility. The capability is genuinely small — a morph table, a trait, and get/set helpers. This package is best framed as a reference design for a ~1-day in-house implementation, not as a strategic dependency.
• CMS and content metadata. SEO titles, Open Graph tags, canonical URLs, hero-image references, and per-post display flags are textbook uses — content teams can extend records without engineering involvement.
• Multi-tenant and per-account customization. Tenant-specific settings, branding values, or feature toggles stored per model instead of per-column, keeping the core schema stable across customers.
• Prototype/MVP acceleration. For a time-boxed discovery build on a legacy Laravel version, this removes an afternoon of plumbing and lets you validate whether customers actually use custom fields before investing in a first-class implementation.
• De-risking schema decisions. Metadata stores absorb "we're not sure what attributes we need yet" — useful when product requirements are still being discovered and premature columns would be expensive to unwind.

Product caveat: it does not support the decisions most teams eventually want — filtering, sorting, and reporting on metadata at scale. Plan for that as a separate bet.

When to Consider This Package

Consider it when:

• You are on legacy Laravel (5.x–6.x) with PHP 7.x, where its 2018-era constraints still resolve cleanly.
• You need polymorphic key–value metadata across several unrelated models and want it working today.
• The use case is low-volume, read-mostly, non-critical — SEO fields, display preferences, annotations.
• You are explicitly prototyping and accept that the dependency will be replaced.

Look elsewhere — or build the ~100 lines yourself — when:

• You are on Laravel 9/10/11+ or PHP 8.1+. Last release was January 2018 (~7 years), 129 stars, single-maintainer risk. Expect Composer constraint conflicts and no upstream fixes.
• Metadata must be queryable, sortable, indexable, or reportable — native JSON columns with Eloquent casts and whereJsonContains() are the better answer and need zero dependencies.
• You require typed values, validation, or audit trails — arbitrary key–value stores drift into untyped string soup fast.
• Security or compliance review applies: unmaintained packages are a standing finding, and an abandoned dependency is hard to defend at audit time.
• You need high write volume or bulk metadata operations — the per-model key lookups and JSON-ish storage won't hold up.

Rule of thumb: adopt the pattern, not the package. The in-house version is small, fully owned, and upgrade-proof.

How to Pitch It (Stakeholders)

To executives (30 seconds): This is a small open-source library that lets us bolt flexible "extra fields" onto any record in the app — custom product attributes, per-customer settings, SEO metadata — without a database migration each time. It would speed up our customization roadmap by roughly a day or two per feature. The catch: it was last updated in 2018, has ~129 stars, and is effectively unmaintained, so adopting it as a dependency creates upgrade and security-review risk. Recommendation: don't take the dependency. Copy the pattern into ~1 day of in-house code or use Laravel's built-in JSON columns. Same product outcome, no vendor risk, no maintenance tail.

To engineering: It's a polymorphic meta table plus a trait exposing get/set on any model. That's the whole product surface — a few dozen lines. We can reimplement it against JSON columns or a morph table in under a day, keep it on our Laravel version, and add the indexing and typed-value validation we'll want in v2. Treat the repo as a spec, not a dependency.

To design/product: Custom fields become cheap to ship and cheap to iterate on, but assume they'll be display-oriented at first. If the roadmap needs "filter and sort by custom field," budget that as a follow-on — it's not something this pattern gives us for free.