Inertia Breadcrumbs Laravel Package

Product Decisions This Supports

• Build vs. buy for breadcrumbs: breadcrumbs are a small but cross-cutting UX/SEO concern. This package replaces bespoke prop-sharing and hierarchy code with a thin, server-driven layer, letting the team spend effort on the hierarchy model (the part that's actually product-specific) instead of plumbing.
• Information architecture ownership: breadcrumb definitions live server-side in Laravel and are shared to Inertia as props, so IA/navigation changes ship as backend changes — no coordinated front-end release, no duplicated hierarchy logic per page.
• Roadmap sequencing for discoverability work: supports initiatives like SEO structured data, accessibility (landmark/aria-current correctness), deep-linking, and "where am I" orientation in admin panels, content sites, and catalog/category flows.
• Use cases to prioritize: admin/back-office panels, content hierarchies (docs, blog categories), e-commerce category and product pages, multi-tenant dashboards — anywhere users land deep via search or direct link.
• AI-assisted development investment (new in 1.2.0): the package now ships a Laravel Boost AI guideline and skill, so assistants generate integration code that matches package conventions. This is a signal for the "are we standardizing on AI coding tooling?" decision and reduces the documentation/onboarding tax of adding another dependency.
• Upgrade decision for 1.2.0: additive, developer-experience-only change. No runtime, API, or config changes — no migration, no regression testing beyond a normal CI pass, no impact on the release train. Safe to take on the next routine dependency bump; no reason to schedule a dedicated upgrade.

When to Consider This Package

Adopt when:

• The app is Laravel + Inertia (Vue/React/Svelte) and navigation state is expected to arrive as props rather than be derived client-side.
• Breadcrumbs are structurally derived from routes/resources rather than hand-written per page, and you want one definition reused for UI, tests, and SEO metadata.
• You want a small, single-purpose dependency with a narrow surface area rather than a navigation framework.
• Your team uses (or is piloting) Laravel Boost or other AI coding assistants — 1.2.0's guideline/skill is a genuine onboarding accelerant for new contributors.
• Breadcrumbs are nice-to-have-but-not-load-bearing; the package is small and single-maintainer, which is fine for presentational concerns.

Look elsewhere when:

• You are not on Inertia (Blade/Livewire-only apps should use Diglactic/laravel-breadcrumbs or Spatie's menu/breadcrumb tooling instead).
• Breadcrumbs must be editor/CMS-managed — that's a content-model decision, not a rendering one.
• You need runtime-dynamic, deeply nested hierarchies (per-tenant trees, permission-filtered paths) that exceed route-derived definitions; expect to wrap or extend the package, or build in-house.
• Business-critical dependency risk is unacceptable: single maintainer and a 1.x line means pin versions (^1.2), review before 2.0, and be prepared to fork. Don't adopt it as the only source of truth for navigation without a fallback.
• You need batteries-included SEO/structured-data generation as a hard requirement — verify current capabilities against your schema needs before committing.

How to Pitch It (Stakeholders)

For executives: A small, free, low-risk Laravel package that standardizes breadcrumb navigation and the SEO/accessibility signals that come with it. It removes bespoke code, keeps navigation hierarchy in one maintainable place, and is an afternoon of integration rather than a sprint. The new 1.2.0 release adds guidance files for AI coding assistants, so our AI tooling writes correct integration code on the first try — lower onboarding cost and less rework. There are no breaking changes and nothing to migrate; it's a safe routine upgrade.

For engineering: Server-side breadcrumb definitions shared to Inertia as props; the front end only renders. 1.2.0 adds a Laravel Boost guideline and skill — documentation/agent-context only, zero runtime or API changes, no config or migration steps. Recommended posture: pin ^1.2, treat it as a presentational dependency (not the sole source of navigation truth), and reassess maintainer activity and test coverage before any 2.0. If breadcrumbs become load-bearing, plan a thin internal wrapper so the package can be swapped or forked without touching feature code.