Metadata Bundle Laravel Package

Product Decisions This Supports

• Feature scoping for "custom fields" / metadata. This bundle is the canonical reference for attaching arbitrary key–value metadata to any domain object without altering its core model or running a schema migration per attribute. That capability underpins a recurring product ask: merchant-defined product attributes, per-tenant configuration, CRM IDs and internal flags on customers, SEO/OpenGraph overrides on catalog entities, and lightweight tagging/segmentation. Use it as prior art when scoping any of those.
• Build vs. buy — resolved to "build, informed by prior art." At 3 stars, 0 dependents, and archived/read-only status, this is not a procurement or adoption decision. It is a make decision where someone else has already sketched the design. The reusable insight is the split between a storage-agnostic metadata component and a thin framework integration layer — copy that separation, not the code.
• Roadmap sequencing. If "let customers extend our data model themselves" is on the roadmap, this bundle shows the enabling primitive (metadata-by-subject) and, crucially, where the seams belong so persistence can be swapped (Doctrine JSON columns vs. EAV tables vs. document store) without rewriting the domain-facing API.
• Architecture guardrail for the Laravel side. The package is a Symfony bundle, not a Laravel package; it cannot be installed as a dependency in a Laravel app without dragging in Symfony container/HTTP-kernel and Doctrine assumptions. Its value to a Laravel team is a schema and interface blueprint: a metadata table keyed by (subject type, subject id, key), plus a repository contract behind an internal MetadataStore interface.
• De-risking an inherited Sylius integration. If the organization already runs Sylius and this bundle is in the dependency graph, the decision becomes "how fast do we internalize or replace it," not "should we adopt it."

When to Consider This Package

Consider it (narrowly) when:

• You need a worked reference implementation of object-metadata mapping and want to see how one team solved subject typing, identifier stability, and hydration before designing your own. Read the source; do not depend on it.
• You are already on Sylius with this bundle present, and must choose between vendoring/forking and replacing it with a first-party implementation.
• Your metadata needs are read-heavy and loosely structured, and your team can absorb the code as first-party.
• You have engineering capacity to own it — realistically 1–3 weeks to internalize, test, and take ownership of a thin bundle, or a few days to reimplement its schema and repository against Eloquent in Laravel.

Look elsewhere when:

• You need active maintenance, security patches, or a support SLA. Archived plus read-only plus zero dependents means no upstream triage, no advisories, and no compatibility work for current PHP, Symfony, or Doctrine majors. Every line adopted becomes owned code on day one.
• You are on a Laravel or greenfield Symfony 6/7 codebase. In Laravel, native JSON columns, Eloquent casts, and a small repository cover most of this with far less surface area; in modern Symfony, Doctrine JSON/JSONB plus property-info do the same.
• Your metadata is high-volume or query-heavy. Pure key/value blobs push filtering and sorting into application code, which degrades badly at scale; prefer typed JSON columns with database-side indexing.
• Your team cannot name an owner for a fork. Adoption without a maintainer is a governance liability that dependency scanners will flag quarterly.
• The score itself — 0.0225 package score against a 5.87 opportunity sub-score — reads as validation of the problem space, not the artifact. Object metadata is a real recurring need; this specific package is abandoned.

How to Pitch It (Stakeholders)

To executives: This is a small, archived, single-maintainer Symfony integration bundle with zero downstream users, so we should not take it as a production dependency — in a Laravel stack it does not even install without pulling in a parallel Symfony container and Doctrine layer. What is valuable is the design pattern: separating a generic metadata layer from framework plumbing so we can let customers attach their own attributes without a database migration per attribute. Recommendation: a short internal spike (1–2 weeks) to validate the model against our real query patterns, then build a small first-party implementation — roughly a metadata table, an internal MetadataStore interface, and one Eloquent adapter — that we fully control. Net effect: low one-time cost, removes a recurring source of migration work, and avoids inheriting an unmaintained dependency.

To engineering: Treat sylius/metadata-bundle as a reference implementation to read, not a package to install. The archived status and zero dependents mean all upgrade and security burden transfers to us immediately, and the Symfony bundle layer is worth essentially nothing outside a Symfony kernel — assume we are evaluating the concept and a handful of PHP classes, not the shipped artifact. Take two lessons: (1) the component/integration split, and (2) the subject contract — a stable getMetadataIdentifier() string (cast ints, deterministically join composite keys) plus a lazy metadata collection populated on load and written through on flush. Before writing any abstraction, confirm whether a typed JSON column with a composite index on (subject_type, subject_id, key) and a capped value size already satisfies our access patterns. Front everything with an internal MetadataStore interface so a future maintained package costs exactly one adapter to swap in. If we do vendor any source, name an owner, add CI plus a PHP version matrix and static analysis, and put it on the dependency-review list before the first deploy.