- Is sylius/metadata-bundle compatible with Laravel?
- No. It is a Symfony bundle built around Symfony's kernel, dependency injection, bundle registration, and Doctrine ORM as the persistence layer. Laravel uses a different container and Eloquent by default, so the bundle layer is dead weight in a Laravel application. The transferable idea is the metadata schema and subject-side interface, not the package itself.
- What does sylius/metadata-bundle do?
- It adds flexible, arbitrary metadata to PHP objects, primarily Sylius resources and entities, without changing the subject table's schema. Metadata rows are keyed by subject class, subject ID, and metadata key, and a subject-side interface makes the association feel native. The Symfony bundle provides service definitions, Doctrine mapping, an event subscriber, and a form type around the sylius/metadata component.
- How do I install sylius/metadata-bundle?
- You would install it with Composer in a Symfony application that already has compatible Symfony and Doctrine versions. In a Laravel app, Composer installation is possible in principle but not advisable because you would be bootstrapping a parallel Symfony container path just to obtain one table, one repository, and a lifecycle hook. The repository is archived, so expect dependency scanners to flag it as abandoned.
- Can I use sylius/metadata-bundle with Eloquent instead of Doctrine?
- No. The bundle registers Doctrine mappings and a Doctrine event subscriber, and it assumes Doctrine ORM persistence. Laravel's equivalent is a polymorphic Eloquent relation using metadatable_type and metadatable_id, optionally combined with JSON or JSONB columns and casts. You would reimplement the pattern rather than swap the ORM underneath the bundle.
- Is sylius/metadata-bundle maintained?
- No, the repository is archived and read-only. There is no patch stream, no security response, and no compatibility work for current PHP, Symfony, or Doctrine majors. Doctrine ORM 3's shift away from annotation mapping is a likely break, and the bundle's mapping files and event subscriber are exactly the surfaces that would fail.
- Does sylius/metadata-bundle support Laravel 10 or Laravel 11?
- There is no official Laravel support for any version. The package is a Symfony bundle and does not ship a Laravel service provider, config file, or Eloquent integration. Checking Laravel version compatibility is therefore not meaningful; the blocker is the Symfony and Doctrine architecture, not the Laravel release number.
- How do I add arbitrary metadata to Laravel models without schema changes?
- Use a polymorphic metadata table with metadatable_type, metadatable_id, key, name, and value columns plus a composite index, then add a HasMetadata trait and relationship to your models. For simpler cases, a JSON or JSONB column with an array cast may be enough. Model observers or events can stand in for the bundle's Doctrine subscriber, and a repository contract can be bound in Laravel's service container.
- What are the best alternatives to sylius/metadata-bundle for Laravel?
- The strongest alternative is a native Laravel implementation using polymorphic Eloquent relations, JSON columns with casts, and a small metadata trait. Packages such as spatie/laravel-schemaless-attributes can cover schemaless attribute storage, but evaluate them against your querying and validation needs. Treat sylius/metadata-bundle as prior art for the schema and interface design, not as a dependency.
- Can sylius/metadata-bundle store typed or queryable metadata?
- The component's model is essentially key-value metadata addressed to a subject, which is convenient for flexible annotations but weak for filtering if you treat values as opaque strings. Queryable metadata changes the schema decision entirely and usually argues against a pure key-value blob, because you need indexes, typed columns, or database-specific JSON indexing. In Laravel, decide up front whether you need JSONB indexes, dedicated columns, or a separate typed attributes table.
- What are the production risks of using an archived Symfony bundle in a Laravel app?
- You would carry an unmaintained Symfony and Doctrine integration into a Laravel application, with no security response and no compatibility work for current PHP or Doctrine majors. Renaming a model silently orphans data because subject_class stores a hard-coded FQCN, and multi-tenancy requires index-level tenant scoping rather than application-only filtering. Expect dependency scanners to flag the package as abandoned for as long as it remains in composer.json.