aubinlrx/laravelrepositories
Repository pattern helpers for Laravel: wrap Eloquent models behind clean interfaces so data access is easier to organize, swap, and test. A lightweight package for structuring queries, keeping controllers slim in larger apps, and defining explicit contracts between application layers.
Install and confirm it even loads before writing a line of domain code. This package dates to May 2015 (Laravel 5.0/5.1 era), so treat installation itself as the first test of whether you can use it at all.
composer require aubinlrx/laravelrepositories
Because it predates Laravel 5.5 package auto-discovery, you will almost certainly need to register the service provider manually in config/app.php:
'providers' => [
// ...
Aubinlrx\LaravelRepositories\RepositoryServiceProvider::class,
],
Verify the real namespace by reading the package's composer.json autoload.psr-4 block and src/ directory — do not trust guessed class names from any tutorial. If a config file ships with it, run php artisan vendor:publish and inspect what appears under config/.
Where to look first, in order:
composer.json — required PHP and illuminate/* constraints. This tells you immediately whether it will coexist with your Laravel version.src/ — find the abstract/base repository class. That class is the entire API surface; everything else is ceremony around it.First use case — the canonical loop:
// app/Repositories/Contracts/UserRepositoryInterface.php
interface UserRepositoryInterface
{
public function find($id);
public function all();
public function create(array $attributes);
public function update($id, array $attributes);
public function delete($id);
}
// app/Repositories/Eloquent/UserRepository.php
class UserRepository extends AbstractRepository implements UserRepositoryInterface
{
public function __construct(User $model)
{
$this->model = $model;
}
}
Bind the interface in a (your own) service provider, then inject it into a controller. The value is that controllers never touch User::where(...) directly — you get a seam for testing and a single place to hang query logic.
One interface per aggregate, not per table. The package gives you a generic base with find/all/create/update/delete and likely paginate. Resist the urge to put every query in the base class. Declare domain-specific methods on the interface (findByEmail, activeWithOrders) and implement them in the Eloquent subclass. This keeps the interface honest about what the app actually needs.
Bind interfaces to implementations in your own provider. Do not rely on whatever the package's provider does beyond registering itself. A dedicated RepositoryServiceProvider with explicit $this->app->bind(...) calls is the pattern that survives contact with a real codebase and makes the swap point obvious:
$this->app->bind(
UserRepositoryInterface::class,
EloquentUserRepository::class
);
Inject into services, not just controllers. The repository pattern pays off when a service/action class composes two repositories inside a transaction. Controllers that inject one repository and immediately ->all() are just adding indirection for its own sake.
Keep Eloquent out of the interface signature. Return plain models or collections; avoid returning Builder instances from public methods. The moment an interface method returns a query builder, every caller is coupled to Eloquent again and the seam is decorative.
Use it as your test seam. This is the strongest day-to-day argument for the pattern here. In tests, rebind the interface to an in-memory fake:
$this->app->instance(UserRepositoryInterface::class, new FakeUserRepository());
Then test controllers and services without touching a database. For integration tests, point DB_CONNECTION at sqlite :memory: and run migrations — the Eloquent implementation works fine there.
Eager loading belongs in the implementation. Add methods like allWithRelations(array $relations) rather than letting callers reach through to the model. If the base class exposes a with() passthrough, prefer your own method so the eager-load contract is documented and testable.
Watch for criteria/filter support. If the package ships a criteria or filter mechanism, use it for cross-cutting query concerns (soft-delete scoping, tenant scoping) rather than copy-pasting where('tenant_id', ...) into every method. If it does not, a small trait on your base subclass is cheaper than adopting a second package.
This is essentially abandonware — plan accordingly. Last release 2015, 12 stars, no activity since. Concretely:
illuminate/* constraint will likely block installation on Laravel 6+. Expect to either pin an old Laravel or fork the package and loosen the constraint yourself.array/callable usages from that era sometimes break on PHP 8.The honest recommendation: copy the pattern, not the dependency. The base repository class in this package is probably 100–200 lines. Reading src/, extracting the useful parts into app/Repositories/AbstractRepository.php, and deleting the composer requirement gives you identical day-to-day ergonomics with zero maintenance risk. Do this unless the package has a specific feature (criteria, caching decorator) you genuinely need.
Debugging container bindings. When a repository method seems to run the wrong implementation, confirm the resolution:
dd(get_class(app(UserRepositoryInterface::class)));
A missing or duplicated binding is the most common failure mode with this pattern, and it fails silently with a generic BindingResolutionException only when nothing is bound.
Mass assignment and fillable. Base create/update implementations typically call $model->fill($attributes). If you get MassAssignmentException, that is Eloquent's $fillable/$guarded config, not the package. Decide policy once per model rather than adding $guarded = [] everywhere.
Avoid repository-within-repository. It is tempting to call one repository from another for "reuse." This creates hidden transaction and N+1 problems. Compose at the service layer instead, where the transaction boundary is explicit.
Extension points worth knowing: the abstract repository class (subclass it for shared behavior like default ordering or soft-delete handling), the service provider's bindings (override them in your app provider — later bindings win), and any config file (set defaults there rather than in constructors). If the package offers a caching decorator, wrap the binding rather than caching inside the Eloquent implementation, so cache invalidation stays in one place.
N+1 will bite quietly. Repository methods that return collections of models encourage loops in views. Add ->with(...) at the repository level proactively and use Laravel's query log or DB::listen during development to catch it.
Do not let the pattern become a religion. If a controller needs one bespoke read query used in one place, writing User::where(...) there is fine. The repository is for queries that are reused, need swapping in tests, or encode domain rules — not a mandatory gateway for every Eloquent call.
How can I help you explore Laravel packages today?