Laravel Inertia Dataproviders Laravel Package

Product Decisions This Supports

• Architecture decision: how data reaches Inertia pages. This package is a thin convention layer for composing the props that Laravel controllers hand to Inertia views, keeping controllers from accumulating query logic and ad-hoc array shaping. It supports the decision to standardise prop composition rather than let each controller assemble payloads inline.
• Build vs. buy. The capability is small enough to hand-roll in a day, so the real decision is "adopt an opinionated convention with a third-party maintainer" vs. "own ~200 lines internally." This release does not change that calculus — it is a compatibility release, not a capability release.
• Roadmap / platform timing. v4.0.0 targets Laravel 13. This is the decision-relevant fact: it sets the package's minimum framework version and makes it a downstream dependency of your Laravel upgrade. Any roadmap item that includes a Laravel major bump now has this package on the critical path.
• Risk posture on framework-coupled dependencies. A package that versions in lockstep with Laravel majors will force a package major on every Laravel major. That is a recurring, predictable upgrade tax — useful input when deciding how many such micro-dependencies to tolerate.
• Feature scoping. Nothing in this release adds product-facing capability. If a roadmap item was waiting on this package for new functionality, it is not unblocked by v4.0.0.
• Test-coverage signal. "Comprehensive test suite" is a maintainer-maturity datapoint that supports (mildly) treating this as a low-risk dependency for a small surface area.

When to Consider This Package

Consider it when:

• You are on, or actively planning, Laravel 13, and you want a conventional place to compose Inertia props instead of fat controllers.
• Your Inertia pages need data assembled from multiple sources (queries, policies, formatting) and you want that composition testable independent of the HTTP layer.
• You have several developers or teams touching Inertia controllers and want a shared, enforced pattern rather than per-author style.
• You are comfortable with a small, single-maintainer package whose majors track Laravel majors — and you have a dependency-update cadence that can absorb a major bump per Laravel release.

Look elsewhere (or build in-house) when:

• You are on Laravel 12 or earlier and not upgrading soon — v4.0.0 will not serve you; you would pin v3.x, which means carrying an unmaintained branch. Verify support windows before committing.
• You already have an equivalent pattern (view models, API resources, form requests + presenters) and this would be a second convention doing the same job.
• Your team's tolerance for third-party micro-dependencies is low, or your security/procurement process makes single-maintainer packages expensive to onboard.
• You need guarantees — SLAs, long-term support, security backports — that an individual-maintained package cannot offer. The surface area is small enough that vendoring the pattern is a credible alternative.

Caveat on evidence: the v4.0.0 notes contain a single line — Laravel 13 support plus a test suite. There is no published migration guide, deprecation list, or changelog for behavioural changes beyond the framework bump. Treat the upgrade as likely trivial but verify against your own usage before scheduling it; do not assume compatibility from the version number alone.

How to Pitch It (Stakeholders)

For executives: This is a small internal-plumbing library, not a product capability. The new version's only substantive change is support for Laravel 13 — it keeps us current with the framework rather than adding anything customers see. The decision it forces is a scheduling one: when we move to Laravel 13, this dependency moves with it. Risk is low (small surface area, now with a real test suite), but it is a single-maintainer package, so we should keep the option of replacing it with ~200 lines of our own code if maintenance ever stalls.

For engineering: v4.0.0 is a compatibility major — Laravel 13 support plus a comprehensive test suite. Assume a breaking change relative to v3.x by virtue of the framework floor, not necessarily an API redesign; confirm against our usage and pin accordingly. Two asks: (1) check whether any of our controllers rely on behaviour that changed, before we bump; (2) decide deliberately whether we want this as a standing dependency or as a pattern we own. The package earns its place only if it is genuinely reducing prop-composition logic in controllers — if it is a thin pass-through, we are paying upgrade tax for very little.

Bottom line: adopt on Laravel 13 if the convention is already earning its keep; otherwise this release is a good moment to re-evaluate whether to keep it at all.