Metadata Laravel Package

Technical Evaluation

Architecture fit

• The framing must be corrected before any roadmap discussion: enhavo/metadata is not a Laravel package. It is a component of Enhavo, a Symfony-based CMS, published as a [READ-ONLY] subtree split of a larger monorepo. It is Composer-installable in any PHP project, which is why it surfaces in Laravel-adjacent tooling, but installability is not fit.
• The concept — structured metadata (SEO titles, descriptions, Open Graph/Twitter fields, canonical URLs, robots directives) attached to a content resource rather than baked into a template — is stack-agnostic and maps cleanly onto Laravel idioms (Eloquent JSON casts, a polymorphic metadata table, model observers).
• The implementation is almost certainly not portable. Symfony bundles typically ship Doctrine mappings, DI compiler passes, and event subscribers. The decisive question is whether this package is a thin set of interfaces and value objects (portable, low-risk) or a bundle with persistence and wiring (requires pulling Symfony into a Laravel app).
• From a TPM standpoint this is not a library decision. It is a CMS selection decision wearing a library's clothes. Adopting it standalone in a Laravel codebase would mean owning a foreign framework component with no support path; adopting Enhavo means inheriting this as one of dozens of internal components. Those are different programs with different budgets.

Integration feasibility

• MIT license — clean for commercial and internal use, no legal gate.
• No Laravel service provider, no facade, no publishable config, no artisan commands. Integration in Laravel is manual wiring at best and framework grafting at worst.
• Zero stars, zero dependents, zero package score is the dominant market signal. There is no external production validation, no third-party issue history to mine for failure modes, and no community answer set. Every integration question resolves by reading source.
• The read-only split means the GitHub repository is not the contribution surface. Issues and PRs go upstream to the Enhavo monorepo. We cannot patch in place and expect to track upstream cleanly — any local change is a permanent divergence.

Technical risk

Key questions to resolve before any commitment

1. What does the package actually contain — contracts only, or a full bundle with ORM mappings and DI wiring? (This single answer determines whether the effort is days or weeks.)
2. What are the composer.json constraints on PHP, Symfony components, and Doctrine, and do they collide with Laravel's pinned Symfony versions?
3. Is the Packagist release in sync with the monorepo main branch, or is the split stale?
4. Is this package load-bearing inside Enhavo itself? If yes, it is maintained by proxy. If it is an orphaned helper, it is already dead.
5. Does it define a storage contract (table schema, JSON column, serialization format) that would constrain our data model if we adopted it?
6. Who maintains it upstream, and what is the release history over the last 24 months?

These are one engineer's half-day of work and should gate every subsequent decision. Do not let a spike start before they are answered.

Integration Approach

Stack fit

• Enhavo targets Symfony; our stack is Laravel. Direct consumption means either (a) accepting Symfony components as transitive dependencies inside a Laravel app — tolerable in principle, but it adds surface area and creates version-conflict risk with Laravel's own Symfony-pinned packages at every framework upgrade — or (b) extracting only the dependency-light classes and never touching the framework-coupled ones, which is a fork by another name.
• Laravel already has native, well-understood idioms for this problem: polymorphic metadata tables, JSON casts, attribute casting, model observers, eager loading. The package's semantics transfer; its code likely does not.

Options, ranked

Compatibility and migration path

• Check the PHP version floor against our runtime and CI matrix. Screen for deprecated constructs: dynamic properties (8.2+), implicit nullable parameters (8.4+).
• If we adopt the semantics rather than the code, there is no data migration — we define the schema ourselves on day one and own the evolution story.
• If we adopt the code and later fork away, we inherit whatever storage format it imposed. That is the outcome to design out, not migrate out of.

Sequencing

1. Days 1–2 — Source audit (gating). One engineer reads composer.json, src/, and any tests. Answer the six questions above. Nothing else starts until this lands.
2. Days 3–5 — Sandbox spike. Install into a throwaway Laravel app; attempt to instantiate core classes without Symfony. Record exactly where coupling bites, in writing.
3. Decision gate. High coupling → Option 1. Substantial portable logic → Option 2. Genuinely standalone → Option 3. TPM records the decision and its rationale; this is the artifact that defends the choice a year later.
4. Implementation + tests, behind our own interface so a future swap is a one-file change.
5. Internal documentation. Everything learned in steps 1–2 becomes the doc set. There will be no external docs to lean on.

The sequencing matters more than the timeline: the audit is cheap, the fork is not, and the gate is what prevents a team from drifting into permanent ownership by accident.

Operational Impact

Maintenance

• The read-only mirror means local patches cannot ride a tracked branch without permanent divergence. Any fork is a full ownership transfer — bug fixes, PHP version bumps, security review, indefinitely.
• With zero dependents, assume a bus factor of effectively one (the upstream Enhavo maintainers, for whom this is a minor internal component). Budget ongoing ownership even if we begin as a pure consumer. If we adopt, the honest line item is "0.1–0.2 FTE of maintenance capacity," not "free."

Support

• No community channel, no vendor SLA, no triage. The support model is: read the source, read the Enhavo monorepo, or read nothing.
• Acceptable for a few hundred lines of value objects. Unacceptable for anything with meaningful runtime behavior or user-facing data.
• Internal enablement cost: one engineer becomes the de facto owner and mandatory reviewer for any PR touching metadata. That is a named person, not a team — plan the handover.

Scaling

• Metadata layers are read-heavy and low-CPU. The scaling question is storage and query shape, not throughput.
• Verify retrieval: if metadata is fetched per-record, a listing page of N resources becomes N+1 queries. Standard and solvable in Laravel (polymorphic eager loading, indexed JSON) — but only if we own the implementation.
• If metadata is an unbounded JSON blob, plan for growth limits, index strategy, and a key-evolution story. These are design decisions we should own, not inherit from a package with no changelog.

Failure modes

Ramp-up

• Code volume is likely small: 1–2 days for a mid-level engineer to understand the package, plus 3–5 days to spike and decide. Full native reimplementation, if chosen, is roughly 1–2 weeks including tests and migration of any existing ad-hoc metadata handling.
• The ramp-up cost is not the code. It is the absence of documentation and the need to independently validate every assumption — which is precisely why the audit is a deliverable, not a formality.

Program recommendation

Do not put this on the roadmap as a standalone dependency. The adoption signals — zero stars, zero dependents, no description, no independent release process, read-only mirror — do not support it as anything we would defend in a review. Treat it as a reference implementation and a source of design vocabulary for a native Laravel metadata model. Fund the two-day audit to confirm that conclusion, keep the decision memo, and revisit only if the organization formally evaluates Enhavo as its CMS. If Enhavo is not the CMS, this should never enter our stack.