Schema Breadcrumb Bundle Laravel Package

Product Decisions This Supports

• SEO / rich-results roadmap item: This package emits the BreadcrumbList JSON-LD that Google uses to render breadcrumb trails in search results. If improving organic click-through or SERP presentation on deep pages is on the roadmap, this is a small enabler for that initiative — but the package itself is only one slice of it.
• Build vs. buy — and here the answer is "build": The entire product value is a Twig helper that maps an ordered array of {name, url, image} into one <script type="application/ld+json"> block. That is roughly 30–60 lines of well-understood code. Taking a dependency to avoid writing it is a poor trade at this maturity level.
• Framework-fit decision (important): Despite the framing, this is a Symfony bundle, not a Laravel package. It registers via legacy AppKernel::registerBundles() and exposes a Twig global function. In a Laravel product it cannot be adopted as-is — there is no service provider, facade, config publishing, or auto-discovery. The only transferable decision is the capability: "we should emit BreadcrumbList structured data," implemented as a Blade component or small service class.
• Structured data as a platform capability: One schema type is table stakes. The real roadmap question is whether you're standardizing structured data across templates (BreadcrumbList, Product, Organization, FAQPage, Article) in a single JSON-LD @graph. This package answers exactly one type and cannot compose with others, so treat it as a reference implementation, not a foundation.
• Legacy Symfony maintenance work: If a product surface genuinely runs on Symfony 2/3 and only needs the script tag, this is a near-zero-cost SEO hygiene fix that can ship inside a sprint without a framework upgrade. That is the one scenario where direct use is defensible.
• Vendor/dependency governance decision: A 0-star, 0-dependent, README-only package with a deprecated Travis CI badge is a governance flag even under MIT. If you have SCA scanning, SBOM policy, or maintenance SLAs, this fails the bar regardless of how small the code is.

When to Consider This Package

Consider it only when all of the following hold:

• You are on an older Symfony codebase that still uses AppKernel::registerBundles() (Symfony 2.x/3.x). Symfony 4+ with Flex and Symfony 6/7 differ in registration and autoloading and would require a rewrite anyway.
• You need only breadcrumb structured data, the data already exists as an ordered array at render time, and you have no requirement for validation, URL canonicalization, localization of labels, or multi-schema graph composition.
• You are willing to accept a dependency with 0 stars, 0 dependents, no release history, no visible test suite, and no security policy — i.e., effectively unmaintained, with no upstream fix path.
• You have smoke-tested it on your actual PHP version in staging, because there are no version constraints or CI signals to rely on.

Look elsewhere — or write the helper yourself — when:

• You are on Laravel (incompatible as distributed), or on Symfony 4+/6/7 (different registration and autoloading model).
• You need structured data beyond breadcrumbs, or need a single JSON-LD @graph combining several schema types. One script per type is harder to validate and maintain.
• You have dependency governance (SCA scanning, license/SBOM policy, vendor maintenance expectations). This does not clear it.
• You need breadcrumbs derived from routing or a menu, translated labels, or <noscript>/microdata fallbacks — none of which are covered here.
• SEO correctness is business-critical and must be tested. The package ships no validation tooling, so you'd own the Rich Results Test and snapshot tests regardless — at which point you may as well own the code.

For teams that want a maintained dependency rather than hand-rolled code, spatie/schema-org is the better buy: Laravel-native, actively maintained, and composes with other schema types.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a very small SEO utility that adds the machine-readable breadcrumb data Google uses to display breadcrumb trails in search results. The upside is real but modest — better SERP presentation and click-through on deep pages — and the build cost is near zero. The catch is that the library itself has no user base and no active maintenance, so I do not recommend adopting it as a strategic dependency. My recommendation is to treat it as a reference and implement the equivalent (~50 lines) in-house, or fold breadcrumbs into a broader structured-data initiative where they are one of several schema types we emit. Either path gives the same SEO value with no third-party risk and costs well under a day of engineering.

For engineering (summary): exs/schema-breadcrumb-bundle is a Symfony bundle, not a Laravel package. It exposes a Twig function getJsonBreadcrumb(items) that serializes an ordered array of {name, url, image} into a schema.org BreadcrumbList JSON-LD <script> block, with 1-indexed position derived from array order. It targets the legacy AppKernel registration era and will not install cleanly into a modern Laravel or Symfony 4+ app. Signals: 0 stars, 0 dependents, MIT, README-only maturity, deprecated Travis CI, no visible tests or version constraints. Risks: abandoned upstream, no PHP 8 / Symfony 5+ compatibility, no schema validation, XSS if name/url/image are not escaped inside the <script> context, json_encode silently returning false on invalid UTF-8, and array-order-as-hierarchy breaking quietly on reorder. Recommendation: do not add as a dependency. Reproduce the behavior in our codebase with (1) a BreadcrumbList builder taking explicit position from a DTO rather than array order, (2) json_encode with JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE | JSON_THROW_ON_ERROR, (3) a Blade <x-breadcrumbs-schema> component (or Twig extension on Symfony), and (4) a snapshot test asserting the tag parses as valid JSON plus a manual pass through Google's Rich Results Test. Identical SEO value, no third-party risk, under a day of work.