Breadcrumbs Laravel Package

Product Decisions This Supports

• Headless / SPA breadcrumb data layer — Because the fork strips Blade rendering, the package returns breadcrumb definitions as plain data. That makes it the natural fit when the rendering surface is Inertia/Vue/React, a mobile client, a JSON API, or a custom design-system component rather than a Blade template. Product can ship consistent navigation trails across surfaces without duplicating route-to-trail logic.
• SEO structured-data roadmap item — Breadcrumb data is the prerequisite for schema.org/BreadcrumbList JSON-LD. If breadcrumb rich results or navigational clarity in SERPs is on the roadmap, this package gives you the raw trail to emit in a JSON-LD block or API payload, independent of the visible UI.
• Design-system / theming flexibility — Decouples "what the trail is" from "what it looks like." Marketing or design can restyle breadcrumbs (or A/B test a new trail treatment) without waiting on PHP changes; front-end owns presentation.
• Build vs. buy call — The underlying logic (route-aware, closure/definition-based breadcrumbs) is already solved by the mature upstream diglactic/laravel-breadcrumbs. A fork is a "buy-with-fork" posture: you inherit proven trail-building semantics while owning the presentation contract. Decision reduces to: fork-and-trim vs. reimplement — reimplementation has no product upside.
• Multi-channel product surfaces — Same breadcrumb definitions serve web, embedded widgets, and API clients, tightening consistency across touchpoints a PM is accountable for.

When to Consider This Package

Adopt when:

• The front end is NOT Blade-first (Inertia, Livewire with custom components, SPA, mobile, or external consumers).
• You need breadcrumb data to feed a design-system component, a JSON API, or JSON-LD schema output.
• You already like diglactic/laravel-breadcrumbs' definition model and want to drop its rendering layer.
• You are inside the Saucebase ecosystem (this is scoped as a Saucebase utility) or comfortable owning a fork.

Look elsewhere when:

• You need server-rendered Blade breadcrumbs out of the box — use upstream diglactic/laravel-breadcrumbs directly; the fork is the wrong tool by design.
• Community support and adoption matter — 0 stars and 0 dependents means effectively no external bug-finding surface and a single-vendor lifeline. Upstream carries the community weight.
• You avoid forks of forks as policy (this is a fork of a fork lineage). Fork maintenance drifts as upstream evolves; confirm the trim is small and the sync cadence is real.
• You need vendor guarantees / SLAs — MIT plus a solo small-project maintainer is the opposite of procured support.

Risk flags to weigh: zero dependents is a strong "unproven in the wild" signal; the package provides no unique capability upstream lacks except the deliberate absence of Blade rendering, which you could achieve with a thin adapter on top of upstream. Prefer this only if trimming is genuinely valuable to your architecture, not for novelty.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed utility that gives us breadcrumb navigation as structured data instead of pre-rendered HTML. Practically, that means one place defines the trail — every surface (web app, design system, API clients) renders it consistently, and we can emit breadcrumb structured data for search results without extra work. Cost is effectively zero, and the decision is reversible: it builds on a widely used upstream package, so if it stops fitting we fall back to the upstream in hours.

For engineering: Take diglactic/laravel-breadcrumbs, remove the Blade renderer, keep the definition API. You get a clean data contract — feed it to Inertia props, JSON, JSON-LD, or your component library. Caveats: it's a young fork (no external dependents), so pin the version, track upstream diffs, and treat any rendering logic as ours to own. If you want zero fork risk, the same outcome is achievable by consuming upstream's data and rendering outside Blade — factor that trade-off before committing.

For design/marketing: Breadcrumb styling and copy are no longer trapped in PHP templates. You own presentation and can test trail treatments independently; we only need to agree on the data shape once.