Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Inertiajs Tables Laravel Query Builder

Inertiajs Tables Laravel Query Builder Laravel Package

protonemedia/inertiajs-tables-laravel-query-builder

Inertia.js tables powered by Laravel Query Builder. Build interactive data tables with sorting, filtering, searching, and pagination, with server-side query handling and a Vue/React front end.

View on GitHub
Deep Wiki
Context7

Inertia.js Front-end Components for Spatie's Laravel Query Builder

Frequently asked questions about Inertiajs Tables Laravel Query Builder
Is protonemedia/inertiajs-tables-laravel-query-builder still maintained?
The repository is archived and the last release was 21 February 2023, so there is no active maintenance, no security patch stream, and no CVE response. Bug fixes and Laravel, Inertia, and Vue compatibility work become your responsibility. Many teams still run it successfully, but treat it as vendored code you own rather than a dependency you can rely on for updates.
Does it support Laravel 10, Laravel 11, and Vue 3?
Compatibility has to be validated, not assumed: the final release predates the current Laravel, Inertia, and Vue major lines, and Composer constraints or peer dependencies may block upgrade paths. The package was built for the Laravel 8–10 era Inertia/Vue stack. Run a short installation spike against your exact versions before committing to it.
How do I install and set up Inertia.js tables with this package?
Adoption is a composer require plus registering the table component in your Inertia front end, which is days rather than weeks for a team already on Inertia. The real effort is per table: enumerate allowedSorts, define allowedFilters, and configure searchable relationships on the PHP side. Because the repository is archived, pin the exact version you validated in composer.json instead of floating constraints.
How does the package prevent SQL injection from sort and filter query parameters?
It wraps spatie/laravel-query-builder, so user-supplied parameters are constrained by explicit allow-lists such as allowedSorts, allowedFilters, and allowedIncludes. Anything not on the list is ignored rather than passed into orderBy or where, which is a genuine improvement over hand-rolled tables that pipe ?sort= straight into the query. The security-sensitive query building lives upstream and is still actively maintained.
Can I use the backend with React, Svelte, or a separate SPA instead of Vue?
The PHP half converts a declarative query-builder contract into an Inertia-shareable payload, so the backend contract survives a frontend rewrite to React, Svelte, or a plain JSON API for a separate SPA. Only the bundled table shell—sort headers, search input, filter controls, pagination, column selector—is frontend-specific. That separation is why the backend is the more durable part of the package.
What should I do if Composer can't resolve the package against my Laravel version?
First determine whether the conflict comes from the package's own constraints or from spatie/laravel-query-builder. The archived layer is comparatively thin glue, so widening constraints in a fork of just that piece is often feasible. If resolution needs deep changes, a small in-house table component is probably cheaper than maintaining a fork.
Is there a maintained successor to this package?
The vendor has rebranded and the package lineage appears to have a successor under a new namespace, but verify that rather than assuming it. Check the vendor's current GitHub organisation and Packagist listings, then compare the successor's API and migration delta against this package. If the migration is small, you are really evaluating the successor, not this one.
Should I use this package or build my own Inertia table with spatie/laravel-query-builder?
For most teams, spatie/laravel-query-builder plus roughly 200 lines of in-house Inertia table component costs three to five engineer-days and eliminates the abandoned dependency entirely. Choose this package when per-table setup cost dominates and your stack matches the versions it was built against. Choose the in-house route when you need long-term maintenance or features the package does not provide.
Does it support row selection, bulk actions, exports, or saved views?
No—row selection with bulk actions, CSV export, saved views, and virtualized rows are outside the package's scope. If your product needs them, you will be extending or forking the front-end component, at which point the archived dependency is yours to maintain anyway. Decide this before adopting, because needing a fork changes the build-versus-buy math.
What are the production risks of depending on an archived Composer package?
The main risks are no patches or CVE response on an archived repository, framework drift when Laravel, Inertia, or Vue ship majors, and transitive breakage from a major bump of spatie/laravel-query-builder. Blast radius is limited because this is presentational glue that a small custom component can replace. Pin versions, name an owner for any fork, and set a review cadence for framework upgrades.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
cgv/localized-resource