Laravel Inertia Dataproviders Laravel Package

Product Decisions This Supports

• Build vs. buy for the Inertia prop layer. laravel-inertia-dataproviders formalizes how page props are assembled for Inertia responses — instead of ad-hoc arrays and closures scattered across controllers, props come from dedicated provider classes. This is a "convention purchase": cheap to adopt, cheap to remove, and it directly reduces the surface area of controller code that PMs end up funding refactors of.
• Roadmap timing for the Laravel 13 migration. v4.0.0 is explicitly a Laravel 13 compatibility release. That makes the package a dependency signal on your platform roadmap: if the app is targeting Laravel 13 this cycle, this package is already aligned; if not, you must pin 3.x and budget the bump. Either way the decision is now known rather than discovered mid-sprint.
• Performance / payload work on data-heavy screens. The provider pattern is where lazy/deferred and partial-reload prop behavior gets expressed. If the roadmap includes "make the reporting dashboard not take four seconds," this is a legitimate implementation lever, not just a code-style preference.
• Testability as a quality investment. The v4.0.0 release ships a "comprehensive test suite," which is a proxy for maintainer seriousness. Prop classes are unit-testable without an HTTP round trip, which lowers the cost of regression coverage on page data — a recurring ask from engineering leads.
• Vendor-risk and fork decisions. Single-maintainer package. v4.0.0 being a clean major with tests is a positive maintenance signal, but it does not change the underlying concentration risk. The PM decision is not "adopt or not" — it is "adopt behind a thin internal wrapper so a future fork or replacement is a contained change."

Caveat: this assessment is derived from the v4.0.0 release notes and package scope only; no repository metrics, download data, or security history were available at review time. Verify maintenance cadence and test coverage before treating the risk read as final.

When to Consider This Package

Consider adopting when:

• You are on Inertia.js + Laravel, and controllers or page routes have accumulated large prop arrays, duplicated query logic, or closures that are awkward to test.
• You want prop assembly to be a named, injectable, unit-testable unit rather than an inline array — particularly on teams where multiple engineers touch the same controllers.
• You are planning or currently executing a Laravel 13 upgrade. v4.0.0 is the line that supports it; adopting now avoids a second migration later.
• You need partial reloads / lazy props to be a first-class, consistent pattern across many pages rather than a per-developer improvisation.
• You want a small, MIT-licensed, opt-in dependency rather than a framework-level commitment.

Look elsewhere when:

• You are staying on Laravel 11 or 12 for the foreseeable future. Do not take v4.0.0; stay on the 3.x line. v4.0.0 is a major and the framework bump is a hard compatibility gate — plan the upgrade as a coordinated app + dependency change, not a routine composer update.
• Your data boundary is already typed DTOs (e.g. spatie/laravel-data) or API Resources. Adding a second prop-assembly convention creates two ways to do the same thing; pick one.
• You are API-first / not using Inertia. The package has no role.
• You require vendor SLAs, guaranteed support windows, or multi-maintainer bus factor. This is a small-team package; that is a real constraint, not a formality.
• The team is small enough that inline props are genuinely fine. Convention packages pay off with scale and turnover; below that threshold they are ceremony.

How to Pitch It (Stakeholders)

For executives (one paragraph): We're evaluating a small, free, open-source Laravel add-on that gives us a standard way to feed data into our Inertia-based screens. The practical payoff is less duplicated query logic in controllers, page data that can be tested without spinning up a request, and a cleaner path to trimming slow dashboards. The new v4.0.0 release adds support for Laravel 13 and ships with a substantially expanded test suite, which is the signal we wanted before committing. Cost is negligible; the main risk is that it's maintained by a very small team, which we mitigate by keeping our usage behind a thin internal wrapper so we can swap or fork it later without a rewrite.

For engineering leads: v4.0.0 is a major release whose headline change is Laravel 13 compatibility, paired with a comprehensive test suite. Treat it as a breaking change: audit our Laravel version first, pin to ^3.3 if we're not yet on 13, and schedule the bump alongside the framework upgrade rather than separately. Adoption should be incremental — introduce providers on the highest-churn or slowest pages, wrap the package behind our own base class or interface, and keep the blast radius small.