Laravel Fakerino Laravel Package

Getting Started

Install and wire up (Laravel 5.x era only).

composer require fakerino/laravel-fakerino:^0.0.2

Pin ^0.0.2 explicitly. Release 0.0.2 exists solely to allow Fakerino 0.6.4; letting Composer float down to 0.0.1 pins you to the older core and reintroduces resolution problems you don't need.

The package still predates auto-discovery — 0.0.2 adds no extra.laravel block — so you register it by hand in config/app.php:

'providers' => [
    // ...
    Fakerino\Laravel\FakerinoServiceProvider::class,
],

'aliases' => [
    // ...
    'Fakerino' => Fakerino\Laravel\Facades\Fakerino::class,
],

Then publish the config:

php artisan vendor:publish --provider="Fakerino\Laravel\FakerinoServiceProvider"

Where to look first. config/fakerino.php is where the day-to-day lives — it tells Fakerino which directories hold your fake-definition files (YAML/JSON) and which locale to default to. After that, read the service provider in vendor/fakerino/laravel-fakerino/src/; it is small and tells you exactly which Fakerino classes are bound into the container and under what keys. That binding list is the real API surface — the README is thin and out of date. With 0.0.2 the wrapper is unchanged but the core moved to Fakerino 0.6.4, so also skim vendor/fakerino/fakerino/ for the definition schema this version actually expects; older blog posts describe a different one.

First use case. Don't start by replacing your factories. Define one small fake and call it from a single seeder — that's the shortest path to knowing whether the package earns its place:

// database/seeds/UsersTableSeeder.php
$user = Fakerino::fake('User');

User::create([
    'name'     => $user->get('name'),
    'email'    => $user->get('email'),
    'password' => bcrypt('secret'),
]);

If that doesn't run against your Laravel version, stop reading and go to Gotchas — you are fighting a 2015-era dependency graph, not a bug in your code.

Implementation Patterns

Keep fake definitions in resources/, not database/. Fakerino's value over plain Faker is declarative, reusable definitions: one YAML/JSON file per domain entity, describing the shape of the fake once, consumed everywhere. Point the config path at resources/fakerino/ so the definitions live next to your views and are obvious to reviewers.

# resources/fakerino/user.yml  (keys vary by Fakerino version — re-check against 0.6.4 in vendor)
User:
  fields:
    name:  { fake: FullName }
    email: { fake: Email }
    city:  { fake: City }

Wrap the facade in your own seam. One class, injected where needed, is the difference between "migrating off this in an afternoon" and "archaeology":

namespace App\Support;

class FakeData
{
    public function user(): array
    {
        return \Fakerino::fake('User')->toArray();
    }
}

Every seeder, factory, and test calls FakeData, never the facade. When the package dies (and it is dormant at best), you rewrite one file. This matters more after 0.0.2, not less: a dependency-only bump is a signal that nobody is working on the wrapper itself.

Prefer it for payloads, not for models. The package is happiest generating nested arrays/JSON — the shape of a request body, an API response stub, a webhook. That's a genuinely different job from "give me a valid User row," and the former is where declarative fake definitions actually pay off:

$response = $this->getJson('/api/orders');
$response->assertJsonStructure(Fakerino::fake('Order')->toArray());

Compose, don't duplicate. Define a base fake (Person) and have entity fakes reference it rather than re-declaring name/email/city in six files. This is the package's whole thesis and the only reason to prefer it over fake().

Use it alongside FakerPHP, never instead of it. In a modern seeder, reach for fake() by default and reserve Fakerino for the handful of structurally complex payloads. Mixing the two is fine and saves you from the package's weaker locale and provider coverage.

Seed responsibly. Fakerino has no uniqueness guarantees. For email/username columns, pair it with a real unique() constraint in your migration and retry on collision, or append uniqid().

Gotchas and Tips

0.0.2 is a dependency bump, not a revival. The entire changelog is "Add support for Fakerino 0.6.4" — no auto-discovery, no PHP 7.4+/Laravel 5.5+ work, no new API, no docs. Treat the package as legacy-only. The release does mean the wrapper's upper bound no longer blocks Fakerino 0.6.4, so your resolution fight may be slightly shorter than it was on 0.0.1 — but the underlying fzaninotto/faker pin is still the thing that will collide with a modern app (FakerPHP is its successor). Check the transitive constraint in composer why fzaninotto/faker before assuming you've won.

If you must use it, fork or vendor it. "repositories": [{"type": "vcs", ...}] with a patched fork lets you bump the Faker constraint (and, usefully, add the extra.laravel block). Without that, the dependency resolution fight is not worth winning for a helper library.

Expect 0.6.4 schema drift. Because 0.0.2 only moves the core, any definition files you copied from older tutorials may not match what Fakerino 0.6.4 parses — key names and nesting changed across core versions. Diff your YAML against the vendor fakerino/fakerino README for the installed version, and re-run the tinker smoke test after the upgrade rather than trusting green tests from 0.0.1.

Old-style registration is mandatory. No auto-discovery means forgetting the providers/aliases entries produces a Class 'Fakerino' not found that looks like a broken install but is a config omission. In Laravel 5.5+ you can add the extra.laravel block yourself in a fork and skip this entirely.

Config caching bites. php artisan config:cache is fine, but the fake-definition files are read at runtime — editing a YAML file does not require a cache clear, while editing config/fakerino.php does. Symptom of the latter: your new path is silently ignored. php artisan config:clear first, always.

YAML parse errors are opaque. Malformed definitions surface as generic exceptions from deep inside the parser with no file/line context. Validate the file with a standalone parser before blaming Fakerino, and keep definitions indentation-consistent — tabs will break it.

Missing fake names fail open in confusing ways. Asking for Fakerino::fake('user') when your file defines User (or when the definition directory isn't in the configured path list) tends to return an empty object rather than throwing. Assert on the result in your seeder the first time; don't assume.

Locale support is thinner than Faker's. If you need per-locale names/addresses, verify the provider exists for your target locale in 0.6.4 before building a feature around it — it_IT is the well-trodden path, most others aren't.

Debugging tip: dump Fakerino::fake('X')->toArray() in php artisan tinker first. If that's empty or wrong, the problem is the definition file or the path config — not your seeder, your factory, or your model. Isolate at the facade before touching application code. Do this immediately after upgrading to 0.0.2; it's the fastest way to catch a 0.6.4 schema mismatch.

The migration exit is trivial and worth taking early. Every usage is Fakerino::fake($name)->get($field) — mechanically replaceable with fake()->$field once you flatten definitions into factory states. The 0.0.2 bump doesn't change that calculus; if anything, a dependency-only release confirms there's no roadmap to wait for. Budget it as tech debt the moment you touch the file.