Symfony Fakerino Laravel Package

Getting Started

What changed in 0.1.1: the package now supports fakerino ~0.7. Nothing else in the release notes. It is still a 0.1.x package, so treat the public API as unstable.

Install

composer require <vendor>/laravel-fakerino:^0.1.1
php artisan vendor:publish --provider="<Vendor>\Fakerino\FakerinoServiceProvider"

Laravel 11+ discovers the provider automatically. On Laravel 10 and below, add the provider (and the optional facade alias) to config/app.php by hand.

Where to look first

1. config/fakerino.php after publishing — this is the real surface area of the wrapper. Field definitions, locale, and provider mappings usually live here rather than in code.
2. The facade root class, to confirm which methods proxy through to Fakerino 0.7 vs. which are wrapper-specific sugar.
3. Fakerino's own docs at the 0.7 tag, not master — see the version-skew gotcha below.

First use case

Seeding a local/dev database. In tinker:

Fakerino::fake('name');        // confirm the install works
Fakerino::fake('email');       // confirm locale/provider data loaded

Then wire it into a model factory and run php artisan migrate:fresh --seed against SQLite. If that works end to end, you have validated the provider registration, the config, and the Fakerino 0.7 constraint in one shot.

Implementation Patterns

Use it behind the Faker facade, not beside it. Laravel factories already inject Illuminate\Database\Eloquent\Factories\Factory's $faker. The lowest-friction pattern is to keep factory $faker for standard fields and reach for Fakerino only for the definitions it does better (structured/nested fake data, config-declared schemas). Two fake-data engines in one factory gets confusing fast.

Config-driven definitions belong in config/fakerino.php. If the wrapper exposes declarative field→provider maps, put them in config so a non-developer can add a column without touching a factory. Keep the config file lean; anything conditional belongs in a dedicated class.

Bind an interface in the container. Wrap Fakerino calls behind a small interface (FakeDataGenerator) registered in a service provider. This is what makes tests replaceable and what insulates you from the 0.1.x → 0.2 churn.

$this->app->bind(FakeDataGenerator::class, FakerinoGenerator::class);

Seeders should be idempotent. Fake data regenerates differently every run; guard against re-seeding with firstOrCreate or a truncate() at the top of the seeder. Otherwise db:seed twice and you get UNIQUE violations on emails.

Locale is per-call, not per-app. Set the app-wide default in config and override at the call site for specific factories (e.g. a de_DE address fixture alongside an en_US name). Don't rely on one global locale unless your whole dataset is single-region.

Gotchas and Tips

Pre-1.0 semver is a trap. ~0.1.1 is correct; ^0.1.1 is fine within 0.1 but will happily pull 0.1.9. Commit composer.lock and don't float this dependency in CI.

The fakerino ~0.7 constraint is a hard floor. ~0.7 means >=0.7.0 <0.8.0. If another package in your tree pins fakerino at 0.6.x, Composer will either refuse to install or silently resolve the wrapper to an older release. Run composer why fakerino before upgrading, and composer update "fakerino/*" --with-dependencies to move both together.

Version skew in the docs is the most common time sink. Most Fakerino examples you'll find online were written against earlier or later releases. Verify every method name against the 0.7 tag before pasting it into a factory.

Fake data is not deterministic by default. There is no seed injection in the wrapper. Tests that assert on generated values will flake. Either assert on shape (assertIsString, assertMatchesRegularExpression) or freeze the value behind a stub of your FakeDataGenerator interface.

unique() providers don't know about your database. Fakerino tracks uniqueness in memory per process; it does not consult existing rows. In a loop that inserts into a uniquely-indexed column, wrap the insert in a small retry or pre-generate the full set of values before inserting.

Locale data is incomplete. Some providers have thin or missing translations and will silently fall back to en_US (or throw, depending on provider). Smoke-test each locale you actually ship.

Performance in loops. Resolving the generator from the container per iteration is measurably slow at 10k+ rows. Resolve once outside the loop, and consider chunk inserts over ->create() per model.

Debugging checklist

• php artisan config:show fakerino — catches stale config:cache after editing the config file.
• php artisan about — confirms the service provider is actually registered on older Laravel versions.
• If Fakerino::fake() throws a "class not found" on a provider, you're almost certainly on a fakerino version the wrapper doesn't support — re-check the lock file.

Extension point. Custom fake-data classes and providers are the intended escape hatch. Register them in your own service provider rather than editing the published config, so vendor:publish --force on the next upgrade doesn't wipe your work.