- What is liam-wiltshire/laravel-jit-loader and how does it prevent N+1 queries?
- Laravel JIT Loader is a narrow, single-purpose Eloquent extension that adds just-in-time relationship loading through a trait and a $jit property declared on a model. Instead of calling with() on every query, you list relationships on the model and the package eager-loads them when the model is hydrated. This helps eliminate N+1 queries while keeping model access and call-site code simple. It sits at the ORM layer and is orthogonal to normal query building.
- How do I install laravel-jit-loader with Composer?
- Install it with composer require liam-wiltshire/laravel-jit-loader, then add the package trait to the model and declare the relationships in the $jit property. Integration cost is genuinely low: one use statement and one property per model. Before committing, verify compatibility on your target Laravel version because the latest release dates from November 2020 and predates Laravel 9, 10 and 11.
- How do I configure the $jit property on an Eloquent model?
- Add the package trait to your model and define a protected $jit property listing the relationship names you want loaded just in time, for example protected $jit = ['comments', 'author']. The relationships are then eager-loaded implicitly whenever that model is hydrated, without changing your query-building code. Keep the list as short as possible because every declared relationship loads in every context where the model is used.
- Which Laravel and PHP versions does laravel-jit-loader support?
- The package has not had a release since November 2020, so it predates Laravel 9, 10 and 11 and the PHP 8.x baseline most teams now run. There is no official confirmation that the trait's hook points still exist and behave identically on modern versions. Treat version support as a spike: install it on a branch against your target Laravel and PHP versions, then exercise read, pagination, chunking and serialization paths before trusting it.
- Does laravel-jit-loader work with existing with() eager loading?
- Yes, it is stated to be compatible with explicit with() usage and should not double-load when a relationship is already eager-loaded. That makes it a low-friction addition rather than a replacement for existing query-building code, so you do not need to refactor repositories or controllers up front. Still verify on a branch that endpoints already using with() do not issue duplicate queries.
- How does laravel-jit-loader interact with preventLazyLoading()?
- The package is described as compatible with preventLazyLoading(), but implicit model-level loading changes where queries originate, so confirm behavior with strict mode enabled in non-production. Also check API Resource serialization with whenLoaded to confirm relationships are treated as loaded when expected. Because the loading is declared on the model, debugging moves from reading the controller to knowing the model's $jit property.
- Is laravel-jit-loader safe for pagination, chunking and cursor() queries?
- This needs verification before production use. Pagination, chunking, cursor() and hydration of large collections have materially different cost profiles, and per-model eager-loading on a 100k-row chunk is far more expensive than on a 20-row request. During the spike, exercise read, paginate, chunk and serialization paths and compare query counts before and after.
- Does laravel-jit-loader cause over-fetching on queue jobs, exports or admin endpoints?
- Yes, relationships declared on the model load everywhere the model is hydrated, including queue jobs, exports and internal admin endpoints that never touch the relation. This trades N+1 queries for potentially wasteful preloads on hot paths, the opposite failure mode and one that is harder to notice. Keep $jit lists short and measure added query cost on paths that do not need the relationship.
- Is laravel-jit-loader still maintained, and what should I do if it is abandoned?
- Maintenance risk is high: it has a single maintainer, around 213 GitHub stars and no release in over four years. A package that size is not a community-supported dependency, so assume you own the code if you adopt it and plan a fork or vendoring strategy with a named internal owner. Alternatives include manual with() calls, query-builder packages such as spatie/laravel-query-builder, or a stricter preventLazyLoading() discipline.
- How do I test or measure whether laravel-jit-loader reduces queries in production?
- Treat it as an opt-in pilot rather than a platform standard. Install it on a branch, add the trait to one high-traffic model, and capture query counts and response times with Laravel Debugbar or Telescope on a representative endpoint set before and after. Then apply it to three to five models with documented N+1 history, confirming no double-loading when with() is already present. Roll it out gradually with an easy rollback and an assigned owner.