Laravel Inertia Dataproviders Laravel Package

Technical Evaluation

Architecture fit laravel-inertia-dataproviders sits in the prop-construction layer of an Inertia app — between Eloquent/domain services and the Inertia::render() call. It formalises what most teams hand-roll as controller methods or view-composers: a named, testable class that returns the array of props for a page. That is a good fit for applications where controllers have accumulated 100+ lines of array shaping, where the same prop set is needed by multiple entry points (web page, modal refresh, partial reload), or where frontend/backend prop contracts drift. It is not a fit for small apps or teams without an existing Inertia commitment — it adds an indirection layer that only pays off at scale.

Integration feasibility Low ceremony: Composer install, optionally publish config, define provider classes, reference them from controllers. No database changes, no queue workers, no external services. The practical gate is not the package's API but its framework constraint.

Technical risk

• Laravel 13 is the headline and the risk. A major version bump that tracks a new Laravel major almost certainly drops Laravel 11/12 support and raises the PHP floor. Anyone not on Laravel 13 cannot adopt v4. Confirm the actual composer.json constraints rather than inferring from the changelog.
• Ecosystem timing. Laravel 13 support is only useful if inertiajs/inertia-laravel, the testing helpers, and your auth/permission packages are all Laravel 13-ready at the same time. The package being early is not the same as the stack being ready.
• Single-maintainer surface. Small OSS package with a narrow maintainer base. The added comprehensive test suite materially reduces regression risk (a genuine positive signal — this is the kind of release note that separates maintained packages from abandoned ones), but it does not reduce bus-factor risk.
• Contract drift across the boundary. Data providers return plain arrays; nothing type-checks the shape against the frontend component. Refactors can silently break pages at runtime.

Key questions

1. Is Laravel 13 on our roadmap within the next two quarters? If not, this release is not actionable and we should assess v3.3.x instead.
2. What are the exact illuminate/* and PHP constraints, and does v4 retain any Laravel 12 support window?
3. Does the package handle Inertia v2 deferred/lazy/optional props and partial reloads, or does it force eager evaluation of every provider?
4. What is the test suite actually covering — unit-level provider resolution, or integration through the Inertia response pipeline?
5. Does provider resolution interact with authorization policies, or is that left entirely to the caller?
6. What is the per-request cost of provider resolution, and does it cache or re-resolve on partial reloads?

Integration Approach

Stack fit Laravel 13 + Inertia v2 + Vue/React/Svelte. Works cleanly with the standard HandleInertiaRequests middleware and resource controllers. Fits a conventional modular monolith; no opinion on DDD or hexagonal layering, so it composes with either.

Migration path The changelog describes a framework-support cutover, not an API rewrite — so v3.3.0 → v4.0.0 should be mostly mechanical if we are already on Laravel 13. Order of operations matters: upgrade Laravel first, verify the Inertia adapter and test suite, then bump this package. Attempting the package bump first will simply fail dependency resolution.

If we are on Laravel 11/12, pin to ^3.3 and treat v4 as a forward-looking item, not a task. Note that pinning a major behind current means accepting that 3.3.x likely stops receiving fixes.

Compatibility Validate the full matrix before committing: PHP version floor, inertiajs/inertia-laravel constraint, test tooling (Pest/PHPUnit version), and any static analysis config. Confirm our CI matrix covers the target Laravel version — a package that passes its own tests on Laravel 13 does not guarantee our application's test suite does.

Sequencing

1. Spike (1–2 days): install on a throwaway branch, convert two representative pages, measure diff size and readability.
2. Establish a convention doc — naming, one provider per page or per prop-group, where authorization lives, how providers are tested. Without this, every developer invents a variant and the abstraction becomes a liability.
3. Pilot on one bounded module with heavy prop logic.
4. Roll out incrementally; do not mass-convert. Controllers not yet converted can coexist with converted ones, which makes this a genuinely low-risk incremental adoption.

Operational Impact

Maintenance Expect roughly one forced major upgrade per year, tracking Laravel's annual release cadence. That is a predictable, budgetable cost — but it is a cost, and it lands in the same window as every other Laravel 13-dependent package. Track it in the same dependency-review queue as the framework itself.

Support Community OSS, no SLA, no commercial backing. Acceptable for a non-critical presentation-layer concern that can be replaced with plain arrays in an afternoon; unacceptable as a load-bearing dependency for anything with uptime commitments. Mitigate by keeping provider classes thin and free of business logic, so the escape hatch stays cheap.

Scaling Runtime overhead is negligible — this is array assembly, not I/O. The real scaling concern is what providers do: a provider is an easy place to hide an N+1 query or an expensive aggregate. Enforce a rule that providers orchestrate already-loaded data or explicitly eager-load; do not let them become a second service layer. Cache expensive prop computations upstream of the provider, not inside it.

Failure modes

• Runtime prop-shape breakage — highest-frequency failure. A provider returns a different key set and the frontend fails silently or with a vague undefined error. Counter with contract tests asserting prop keys per provider.
• Provider exception takes down the page — an unguarded query in a provider fails the whole Inertia response rather than degrading a single prop. Decide explicitly whether providers may throw.
• Upgrade-window lockstep — the package, the framework, and the Inertia adapter must move together; a partial upgrade leaves the app unable to install.
• Abstraction sprawl — no convention means inconsistent provider styles, which is worse than no abstraction at all.

Ramp-up The concept is learnable in an hour by anyone fluent in Laravel and Inertia; the API surface is small. Realistic ramp: half a day for a senior developer to be productive, roughly a sprint for a team to internalise the convention and stop writing ad-hoc prop arrays alongside it. The added test suite in v4 is a meaningful onboarding asset — reading the tests is the fastest way to learn the intended usage. Budget review time for the first two PRs per developer to catch anti-patterns early.