Laravel Inertia Shared Data Provider Laravel Package

Technical Evaluation

What this package actually is. ebess/laravel-inertia-shared-data-provider is a thin ergonomic layer over a pattern every Inertia.js + Laravel app already implements by hand: the HandleInertiaRequests middleware returns a share() array of global props. The package replaces inline closures in that middleware with discrete provider classes that are registered and composed declaratively. It is convention and file organization, not new capability.

Architecture fit. Good, with a caveat about what it does not touch. It sits entirely inside the server-side shared-props pipeline and does not affect Inertia's client adapters (Vue/React/Svelte), the protocol, or the response envelope. That means it is swappable and low-blast-radius by construction. The caveat is that shared props are serialized into every Inertia response — this package is a natural place to accumulate query load. Whether it preserves Inertia's lazy/closure-based prop semantics (so a prop is only resolved when requested, and partial reloads with only still skip unrequested providers) is the single most important technical question, and it is unverified from the supplied material. If providers resolve eagerly, this package becomes a performance regression generator that looks like a code-style improvement.

Integration feasibility. Mechanically trivial: one composer require, one service-provider registration (auto-discovery or manual), a handful of small classes, and no migrations, no routes, no queue workers, no published assets beyond possibly a config file. Realistic engineering effort is hours, not days. The blocker is not effort but fit: the last release is 2021-11-04, which predates Laravel 10, 11, and 12. The composer.json require block (minimum PHP and illuminate/* constraints) was not supplied and must be read before anything else — if it caps at ^8.0, adopting this package means either an unplanned framework constraint or running it unsupported.

Technical risk. High for the dependency edge, low for the code. Specific concerns:

• Maintenance risk. Zero stars, single author, one release in November 2021, no changelog beyond "Initial release," no visible CI or security posture. Three-plus years without a tag is the practical definition of unmaintained.
• Documentation risk. The supplied documentation is templated and generic — it refers to <vendor>/<package> and Vendor\Package\PackageServiceProvider rather than real namespace paths. There is no verified README, no API reference, and no stated semver policy. We cannot describe the public surface from what we have.
• Behavioral risk. Provider ordering, key collision handling, override precedence, and eager-vs-lazy resolution are all unspecified in the supplied material.
• Blast radius. Shared props are global. An exception thrown inside one provider breaks every Inertia page in the application, not one screen. That is an unusually wide failure domain for a package this small.

Key questions to answer before a decision.

1. What are the PHP and illuminate/* constraints in composer.json, and do they cover our current and next framework version?
2. Do providers return closures that Inertia evaluates lazily, and does partial reload (X-Inertia-Partial-Data) still work correctly when props are contributed by providers?
3. What is the resolution order, and what happens when two providers return the same key?
4. Is there a contract/interface to type-hint, or only a concrete registry — i.e., is there anything to bind a fake against in tests?
5. How large is the exit? (Our estimate: the pattern is ~50–80 lines of our own code — an interface plus a loop in HandleInertiaRequests. That makes exit cost negligible and reframes the build-vs-buy math.)

TPM read. The value proposition is developer ergonomics in one middleware file. The cost is a permanent dependency edge on an unmaintained, zero-adoption package for a pattern we can reproduce in an afternoon. The asymmetry favors building in-house unless the spike shows the package handles lazy resolution and ordering correctly and we expect the shared-prop surface to grow large enough that the convention pays for itself.

Integration Approach

Stack fit. Laravel + Inertia (server-side adapter), any frontend. The package is irrelevant to which Inertia client we use, so it does not couple us to a frontend decision — a point in its favor. It does couple us to whatever Laravel major the 2021 constraints allow, which is the real fit question.

Migration path. Incremental and reversible, which is the main reason to consider it at all:

1. Verify constraints and framework compatibility first; stop here if it forces an upgrade.
2. Install with an exact pin (1.0.0), not ^1.0. With one release and no patch history, the caret buys no safety and only removes reproducibility.
3. Establish a baseline: capture query count and response payload size for the highest-traffic Inertia page before touching anything. Shared props are global, so a regression here hits every page.
4. Extract one provider at a time from HandleInertiaRequests, starting with the most expensive/least shared prop. Keep the original inline closure commented or behind a flag for one deploy so rollback is a revert, not a rewrite.
5. Wrap it. Even at this size, put a single application-owned class (e.g., App\Inertia\SharedData) in front of the package's registry so provider registration has exactly one call site. That is the seam we cut when we replace it.
6. Only after the first provider is green in staging do we migrate the remaining props.

Compatibility checks. Run php artisan config:cache in staging — a config that ships closures will fail serialization and this is the classic "works locally, null in production" trap. Confirm the provider appears in bootstrap/cache/packages.php or bootstrap/providers.php. Check for published config and diff it against the vendor copy on any future upgrade. There are no migrations to collide, which removes a whole class of risk.

Sequencing. Time-box a spike (one to two days) against a non-critical page section. Explicit abandon criterion: if eager resolution causes measurable query-count growth, if partial reloads break, or if the framework constraints don't cover our matrix, we reimplement the pattern in-house and close the ticket. Do not sequence this alongside a framework upgrade or an Inertia major bump — the variables need to be independent.

Operational Impact

Maintenance. The dependency is effectively frozen. Our owner-of-record is internal: one engineer, a small recurring allocation (an hour or two per framework upgrade cycle) to confirm the package still instantiates correctly. We should assume no upstream patches arrive, and therefore assume that any defect we hit, we fix — via a fork, a patch entry in composer.json, or replacement. Budget for the third option, since it is the cheapest.

Support. No vendor, no SLA, no issue-triage history of any kind. Zero stars means essentially no peer usage — we will not find prior art when something breaks, and we will absorb any bug reports as the first meaningful consumer. That cost is small only because the surface is small.

Scaling. The scaling risk is not concurrency, it is response weight. Every prop contributed by a provider ships on every Inertia response. As the provider list grows, two things degrade: payload size (mitigated by Inertia's partial reloads only if lazy props are preserved) and query count (mitigated by nothing if resolution is eager). A convention that makes it easy to add global props makes it easy to add global props nobody asked for. Enforce a rule: a provider belongs in shared data only if it is genuinely needed on nearly every page, and expensive values are lazy. Re-baseline query count and payload size after migration.

Failure modes to plan for.

• Provider exception ⇒ site-wide 500. Every Inertia page depends on the shared-prop pipeline. Any provider that touches a database or an external service must fail soft (null/default) rather than throw, or it becomes a single point of failure for the whole UI.
• Silent prop shadowing. Two providers returning the same key, or ordering changes on registration, yield wrong data with no error. Add a test asserting the exact shared-prop key set.
• Eager resolution N+1. Manifests as a slow application, not an error, so it will be found in production unless we measure in staging.
• Framework-upgrade breakage. The package's boot()/container assumptions were written for a 2021 Laravel. This will be discovered during the upgrade, at the worst time. Treat it as a known upgrade tax line item.

Ramp-up. Very low for engineers — a new developer reads one middleware file and understands the whole system in ten minutes, which is genuinely better than untangling a 200-line inline share() method. That legibility is the actual product here. The counter-risk is convention drift: without a written rule for what qualifies as shared data, the provider directory becomes a dumping ground and we get the downsides of global props with none of the discipline.

Recommendation for the portfolio. Do not adopt as a strategic dependency; evaluate as a disposable convenience. The pattern is small enough to own outright (~50–80 lines behind our own interface), and owning it eliminates the abandonment, framework-constraint, documentation, and support risks simultaneously at roughly the same upfront cost as the spike. The only scenario where taking the dependency is clearly correct is if the spike shows correct lazy resolution and ordering semantics, the constraints cover our matrix, and we plan to grow the shared-prop surface substantially — in which case pin exactly, wrap in an adapter, and write the exit plan on day one.