Laravel Inertia Shared Data Provider Laravel Package

Product Decisions This Supports

• Build vs. buy — and here the honest answer is "build the pattern, not the dependency." The package does not add capability; it adds structure on top of Inertia's existing HandleInertiaRequests middleware. The entire value is "shared props live in small, injectable, testable classes instead of a growing wall of closures." That is a design pattern we can adopt in a day. The package is a reference implementation, not a platform bet.
• Tech-debt prioritization on the frontend/backend seam. As Inertia apps grow, HandleInertiaRequests::share() becomes a grab-bag: auth user, roles/permissions, feature flags, unread counts, cart totals, locale, flash messages. Every new global prop touches one file and one test surface, so shared props become a merge-conflict hotspot and a source of silent regressions in nav/header for every page. Provider classes make each prop independently testable — a real reduction in blast radius.
• Roadmap shaping / team scaling. If we expect multiple squads to contribute global props, or multiple Inertia apps, a provider convention is cheap standardization. If we have one small app, this is over-engineering and should stay off the roadmap.
• Risk register entry, not a feature entry. With 0 GitHub stars and a single 1.0.0 release from November 2021, we must plan for the maintainer's disappearance. The decision is "do we own ~100 lines?" — which is answerable, and cheap, versus "do we take an unmaintained third-party edge?"
• Performance triage. Per-provider laziness is only a win if we audit it. Adopting the pattern is a good forcing function to check whether shared props are running expensive queries on every request (N+1s in shared data are a classic Inertia scale problem).

When to Consider This Package

Consider it when all of the following hold:

• It still installs on our stack. This is the first gate, not a formality. Verify composer.json constraints against our PHP and illuminate/* versions, and against the Inertia version we run — the package predates Inertia's 1.x/v2 evolution, so closures/lazy props may work differently or not at all.
• We are willing to fork or vendor it. At 0 stars and no release since 2021, treat it as unmaintained source code to be copied and owned. That is fine — it is small — but it must be a conscious decision, not a discovered one.
• We already have shared-prop sprawl. More than roughly five to ten global props, multiple contributors, and at least one incident traced to a shared prop. Otherwise the abstraction costs more than it saves.
• We need testable shared data. Our global props include logic (permissions, counts, flags) that we currently cannot test without issuing HTTP requests.
• It is used as a spike or a template, scoped to one app, behind a short time-box.

Look elsewhere when:

• We need a maintained dependency. No CI signal, no release cadence, no issue activity → not a long-term edge for anything core to the product.
• We are on current Laravel/Inertia. Modern Inertia already supports closures, lazy/optional props, and partial reloads; a plain service class or a small SharedData container bound in a service provider gets us 90% of the benefit with zero risk.
• We want a driver/extension ecosystem. This package does not offer one, so our adapter becomes the extension point — another argument for writing it ourselves.
• The requirement might outlive our Laravel commitment, or if we would be the first meaningful adopter absorbing bug reports for a solo-author package.

How to Pitch It (Stakeholders)

For executives: This is a developer-ergonomics package, not a product capability — it does not ship a user-facing feature and it does not move a roadmap date. What it does is make global page data (who is logged in, permissions, flags, counters) safer to change, which reduces the class of regression where one bad shared prop breaks headers or navigation across the whole app. Our recommendation is not to adopt the dependency: it was last released in 2021, has essentially no community usage, and is small enough that we can implement the same pattern in roughly a day and own it outright. Cost is one engineering day; risk is near zero; the alternative — taking an abandoned third-party edge into a shared code path — is the expensive option.

For engineering: Read this as a design pattern with a reference implementation, and take the pattern. Concretely: extract global props out of HandleInertiaRequests into small provider classes behind a single interface, register them in a service provider, keep the middleware as a thin aggregator, and unit-test each provider in isolation. Do it behind one narrow slice first — the auth user payload or permission list — and confirm the props still resolve correctly under config:cache, queue workers, and partial reloads. Do not add the Composer dependency: at a 1.0.0 tag from 2021 with no subsequent releases, we would be committing to maintain someone else's ~100 lines while also carrying the upgrade risk into future Laravel and Inertia majors. If we do trial the package, time-box it, pin the exact version, wrap it behind our own adapter so call sites never touch it directly, and write down the abandon criterion up front — if the abstraction is not clearly better than our own implementation by the end of the spike, we keep the code and drop the dependency.