Inertiajs Tables Laravel Query Builder Laravel Package

Technical Evaluation

Architecture fit

• The package is a two-part artifact: a PHP side that wraps spatie/laravel-query-builder into an Inertia-shareable payload, and a Vue side that renders a table shell (sort headers, search input, filter controls, pagination, column selector). It assumes a Laravel + Inertia + Vue monolith — the dominant architecture for mid-size Laravel apps — and it fits that shape cleanly.
• The PHP half is the more reusable asset. Sorting/filtering/search/pagination are expressed as declarative allowedSorts / allowedFilters / allowedIncludes on the query builder, which means the backend contract survives a frontend rewrite (React/Svelte Inertia adapters, or a plain JSON API for a separate SPA). That materially lowers the cost of adopting it even if the Vue component is later replaced.
• The design pushes developers toward explicit allow-lists for user-supplied query parameters. That is a genuine security posture improvement over hand-rolled table code, which routinely leaks ?sort= and ?filter= directly into orderBy/where.
• It is a presentational convenience, not infrastructure. Nothing else in the stack should depend on it, which caps the blast radius if it is later removed.

Integration feasibility

• Adoption is a composer require plus a Vue component registration — days, not weeks, for a team already on Inertia. The real effort is per-table: enumerating sortable columns, defining filters, and setting up searchable relationships. Budget per table, not per project.
• The main feasibility question is version compatibility, not capability. Last release is 2023-02-21 and the repository is archived. That predates current Laravel, Inertia, and Vue major lines. Expect to validate, not assume, against the target stack.
• spatie/laravel-query-builder is an active, well-maintained dependency, which is the saving grace: the harder, security-sensitive half of the work is still maintained upstream. The archived layer is comparatively thin glue.

Technical risk

The composite score (~8.8) reads as "well-designed, well-documented, small and focused." That is accurate and also insufficient: for a dependency you intend to keep for years, maintenance status dominates design quality. Treat the archive flag as the deciding input, not a footnote.

Key questions

1. Does a maintained successor exist under the vendor's new namespace, and what is its migration delta? If the answer is "small," this becomes an evaluation of the successor, not this package.
2. What are our target versions for Laravel, Inertia, and Vue — and does the package resolve against them today? This is a one-afternoon spike, and it should gate everything else.
3. Do we need capabilities the package does not provide (row selection/bulk actions, export, saved views, virtualized rows)? If yes, we are forking anyway.
4. What is the realistic build cost of the alternative — spatie/laravel-query-builder plus ~200 lines of in-house Vue table component? For most teams this is 3–5 engineer-days, and it eliminates the abandoned dependency entirely.
5. Who owns the fork if we take one, and what is the review cadence when Laravel ships a major?

Integration Approach

Stack fit

• Strong fit for Laravel 8–10 era Inertia/Vue applications. Fit degrades predictably as the stack moves forward: Laravel 11/12, Inertia v2, and Vue 3.4+ are all outside the package's release window and must be verified rather than assumed.
• For React or Svelte Inertia frontends, only the PHP half applies — worth evaluating on that basis alone if the backend contract is the real prize.
• Not a fit for API-first architectures serving multiple non-Inertia clients; the payload shape is convenient but Inertia-specific.

Migration path

Three viable routes, in ascending order of commitment:

1. Adopt as-is, pinned. Fastest. Accept that a future Laravel/Vue upgrade will force a decision under time pressure. Only defensible if the tables are non-critical or the app has a short horizon.
2. Fork to an internal namespace. Vendor the repository, pin the commit, and own it. Converts an abandonment risk into a known maintenance line item. Preferred route if the tables are load-bearing.
3. Re-implement on maintained primitives. Keep spatie/laravel-query-builder (actively maintained) and replace the Vue table component with an internal one modeled on this package's API. Highest upfront cost, lowest long-term risk; the right call if the successor package is not viable or if we need capabilities beyond it.

The decision should be made on the successor question first. If a maintained successor exists with a small delta, route 1 becomes route 0 — just use the successor.

Compatibility

• Validate: PHP version constraint, Laravel illuminate/* constraints, Inertia adapter version, Vue major, spatie/laravel-query-builder major, and build tooling (Vite vs Laravel Mix). The last one bites silently — 2023-era packages frequently ship Mix-era asset assumptions.
• Check whether the published config and Vue component use Options API vs Composition API and whether that conflicts with our lint/format standards.

Sequencing

1. Spike (1–2 days). Install into a scratch branch on the target stack; build one real table end-to-end. Confirm sorting, a custom filter, relationship search, and pagination.
2. Successor check (parallel). Resolve the vendor-rename question. If a maintained successor exists, re-point the spike at it.
3. Decision gate. Route 1, 2, or 3, with the fork owner named.
4. Pilot (1 sprint). One or two production tables, behind a feature flag where the surface is user-visible.
5. Rollout. Remaining tables incrementally; do not convert the whole admin surface in one release.
6. Establish an upgrade checkpoint. Add the pinned dependency to the pre-upgrade checklist for every Laravel/Vue major.

Operational Impact

Maintenance

• The maintenance burden is transferred, not eliminated. Archiving means the upstream team has stopped absorbing bug reports; every future incompatibility lands on our backlog with no external SLA.
• Estimate 1–3 engineer-days per year of baseline stewardship for a fork (dependency bumps, peer-dep resolution, occasional Vue/Inertia API changes), spiking to 5–10 days around a major Laravel or Vue upgrade.
• The mitigating factor is size: the package is small and focused, so a fork is tractable. This is not a framework-sized abandonment.

Support

• No vendor support, no active issue triage, no security advisories. Internal teams will bring questions to whoever adopted it — name that person before rollout, not after the first incident.
• Documentation lives in the archived repo; it will not track current framework behavior. Assume our internal docs become the source of truth.

Scaling

• Server-side pagination is the correct default and this package enforces it, which is the single most important scaling property for admin tables. Tables stay fast as row counts grow because the database does bounded work.
• Watch for the classic failure modes anyway: COUNT(*) over large filtered sets on every request; search across unindexed LIKE '%term%' columns; eager-loading allowedIncludes that fan out into N+1 or cartesian joins; and relation-based sorts with no supporting index.
• The frontend component is not virtualized — fine for paginated pages of 15–100 rows, not fine if anyone tries to render thousands client-side.
• Budget index work as part of adoption. The package makes it easy to expose a sortable column; it does not make that column indexed.

Failure modes

• Silent breakage on composer update — the highest-probability failure. A transitive major bump changes behavior without an error at install time. Mitigate with a committed lockfile and a smoke test on one table per release.
• Upgrade deadlock — the package's constraints block a Laravel major, forcing an emergency fork mid-upgrade. This is the scenario that turns a two-day adoption into a two-week one; the sequencing above exists to surface it early.
• Filter allow-list gaps — developers expose a filter or sort backed by an unindexed or sensitive column. Not a package defect, but the package's ergonomics make it easy; enforce review on allowedFilters/allowedSorts diffs.
• Search on encrypted or computed columns — produces wrong results rather than errors, which erodes trust quietly.
• Frontend contract drift — teams start depending on undocumented component internals, making the eventual replacement a larger project than it should be. Constrain usage to the documented API.

Ramp-up

• Low for developers already fluent in Inertia and Vue — the component API is conventional and the backend is declarative. Expect under a day for a mid-level engineer to ship a first table.
• Non-trivial for anyone unfamiliar with spatie/laravel-query-builder semantics (filter scopes, allowedIncludes, custom sort classes). One internal walkthrough plus a reference implementation in the codebase covers it.
• The real organizational ramp-up is the ownership conversation, not the code. Assign a maintainer at adoption time; unowned forks decay faster than unowned vendored code, because nobody feels the archive flag.

Bottom line for the decision record: the package is well-designed and cheap to trial, but it is archived, predates the current framework generation, and has minimal ecosystem signal. Approve a short spike only — gated on resolving the successor question — and default to the fork-and-own or re-implement-on-maintained-primitives route rather than adopting the archived artifact directly.