- Is krystal-sf/ux-datatables a Laravel package?
- No. Despite being described as a Laravel-style data table package, the repository is a Symfony UX package built for Krystal's own Symfony projects. It registers through a Symfony Bundle, a DependencyInjection extension, and a configuration tree, none of which have an execution path in Laravel's container. Treat it as a Symfony artifact, not a Laravel candidate.
- Can I install krystal-sf/ux-datatables in a Laravel application with Composer?
- Composer may resolve and install it, but installation is not integration. The bundle registration, service wiring, and config tree are Symfony kernel concepts, so nothing in the package boots inside Laravel's service container. You would end up pulling symfony/form, options-resolver, property-access, and event-dispatcher into an app that already has its own request lifecycle, validation, and authorization.
- Does krystal-sf/ux-datatables support server-side processing with Eloquent?
- The only transferable piece is the server-side DataTables protocol logic: parsing draw, start, length, search, order, and columns, then returning a filtered, sorted, paginated result with counts. That logic is framework-agnostic in principle, but the shipped implementation is wired for Symfony, and no Eloquent or query-builder integration is provided. In Laravel you would be rewriting the adapter yourself.
- Which Laravel and PHP versions does krystal-sf/ux-datatables support?
- No Laravel version constraints are published, because the package does not target Laravel at all. Its PHP and Symfony constraints are not clearly documented, and there is no visible release discipline, semver posture, or compatibility matrix. Before any evaluation you should read composer.json for require, require-dev, and platform constraints; a hard Symfony UX dependency or a PHP ceiling below your runtime is an immediate non-starter.
- How does krystal-sf/ux-datatables compare to yajra/laravel-datatables?
- yajra/laravel-datatables is Laravel-native, widely adopted, and handles Eloquent, query builder, relations, and exports out of the box. The Krystal package offers nothing concrete that yajra does not already provide for a Laravel codebase, and it adds a second abstraction layer that competes with Laravel conventions. If the answer to what this does better is nothing specific, close the ticket.
- Can I reuse the Stimulus or UX front-end from krystal-sf/ux-datatables with Blade and Vite?
- Probably not cleanly. The front-end layer assumes Symfony UX asset registration through AssetMapper or Encore plus a Stimulus controller, which does not map onto Blade with Vite. The controller could be hand-wired, but at that point you are maintaining a fork of a fork. If the renderer is proprietary rather than DataTables.net, you also inherit coupling you cannot version.
- Is krystal-sf/ux-datatables actively maintained and safe for production?
- The signals point to a published-for-convenience internal artifact rather than a supported product: zero stars, zero dependents, GitLab-only hosting, and a description naming one vendor's projects. There is no community validation, no visible test coverage or security response process, and your bugs are not on their roadmap. For production Laravel work the correct default posture is unvetted dependency, not candidate.
- Does krystal-sf/ux-datatables handle soft deletes, whereHas, composite keys, or multi-tenant scoping?
- There is no evidence either way, and that is the problem. Zero dependents means zero field testing on exactly the cases that break data table packages: composite keys, relationship filtering with whereHas, soft deletes, tenant scoping, and large result sets. Any of these would need to be verified and patched by your team before you could trust the output.
- What should I use instead of krystal-sf/ux-datatables in Laravel?
- Use yajra/laravel-datatables for a server-side Eloquent-backed table, or a plain Illuminate database builder with your own DataTables protocol handler if you want full control. If your UI is Livewire or Inertia, the native table components plus DataTables.net on the front end cover the same ground without a framework bridge. All of these keep you inside Laravel's request lifecycle and conventions.
- When would forking krystal-sf/ux-datatables actually make sense?
- Only if you have a Symfony surface in the portfolio, you have confirmed the license allows an internal fork, the server-side layer is standalone rather than Form-type coupled, and the origin repository is still live. Even then, scope it as a build-versus-buy decision for that Symfony app, not a dependency decision for Laravel. If the API is a Symfony Form type, the license is unclear, or the source project is orphaned, reject it.