Schema Context Bundle Laravel Package

Product Decisions This Supports

• SEO / rich-results roadmap: Decides whether we ship structured data (JSON-LD @context / schema.org) for product, article, breadcrumb, FAQ, and organization pages this quarter — and whether that work is a template-level concern or a first-class domain concern.
• Build vs. buy vs. fork: Replaces a likely in-house "just write JSON-LD in the template" pattern with a declarative bundle. The real decision is thin dependency vs. 200 lines of our own code — this package only wins if it saves more maintenance than it creates.
• Content modeling decisions: Schema context layers typically map application entities to schema.org types. Adopting it early nudges entity design (Product, Offer, Article, BreadcrumbList) in a way that pays off later; adopting it late means retrofitting.
• Technical-debt consolidation: Use it as the argument to remove scattered, hand-maintained <script type="application/ld+json"> blocks from views and centralize them under test.
• Prioritization / opportunity sizing: With a score of ~14.5, 1 star, 0 dependents, and a single-source maintainer, the honest PM read is low opportunity, low maturity — this is a spike candidate, not a roadmap commitment.
• Framework-strategy decision: It's a Symfony bundle, not a framework-agnostic library. If our stack is Laravel, this forces a "port vs. pick something else" decision, which is itself a useful forcing function.

When to Consider This Package

Consider it when all of the following hold:

• We are on Symfony (or willing to shim a bundle's service provider / Twig extension into Laravel's container and Blade).
• We need schema.org JSON-LD for SEO and are currently hand-writing it in views.
• The surface area we need is small and stable (a handful of types, no feed generation, no merchant-center complexity).
• MIT license and a small, readable codebase mean we can vendor it, fork it, or read it in an afternoon — supply-chain risk is acceptable because it's tiny.
• We can wrap it behind our own interface so swapping it out later is a one-file change.

Look elsewhere when:

• Laravel-first stack. spatie/schema-org is the mature, widely adopted PHP option; porting a Symfony bundle is usually more work than the bundle saves.
• SEO is already owned by tooling — CMS SEO plugins, headless CMS schema fields, or a marketing platform that emits JSON-LD for us.
• You need guaranteed maintenance: SLAs, security patching, active issue triage, broad schema.org coverage, i18n, or validation against Google's Rich Results test. One star and zero dependents means no community backstop and no signal that anyone else has run this in production.
• Requirements will grow (product feeds, multi-locale markup, A/B-tested rich snippets). A one-maintainer bundle is the wrong long-term substrate for a differentiating capability.
• Release cadence can't be verified — the published last-release date is ahead of today, so treat the project's activity signals as unconfirmed until we check the repo directly.

How to Pitch It (Stakeholders)

To executives: This is a cheap, timeboxed experiment, not a platform bet. Structured data can improve search click-through via rich results, and this MIT-licensed bundle could get us there faster than custom code — but with one star and no downstream users, it carries unproven-maintenance risk. Ask for a 1–2 day spike behind a feature flag; adopt only if it clears our evaluation gates, otherwise fall back to a proven alternative (spatie/schema-org) or ~200 lines of our own code. Zero licensing cost, minimal downside, capped effort.

To engineering: It's a small Symfony bundle for schema.org context/JSON-LD generation. Evaluate on four things: framework coupling (bundle conventions vs. our stack), test coverage and release history, how it maps our entities to schema types, and whether it can sit behind our own StructuredData interface so it's replaceable. Do not let it leak into domain code or templates directly.

The decision we need: approve the spike and the evaluation gates (maintainer activity, coverage, fit, exit cost). Default answer if any gate fails: don't adopt.