Synth Laravel Package

Getting Started

Blinq Synth is a synthetic (fake) data generator for Laravel. Instead of hand-wiring Faker calls into every factory, it inspects your schema and/or existing rows and produces plausible replacements — the practical use case is "I need realistic-looking users, orders, and payments for local dev or staging without copying production PII."

Minimal steps:

1. composer require blinq/synth --dev — almost always a dev dependency, since you don't want a synthesizer running in prod.
2. Publish and open the config: php artisan vendor:publish --tag=synth-config, then read config/synth.php. This is where you set table allow-lists and per-column overrides.
3. Run the discovery/listing command (the README likely exposes something like php artisan synth:list or synth:tables) to confirm it sees your tables and infers column types correctly on your driver.
4. First use case: point it at users and orders, generate ~100 rows into your local DB, and check FK relationships survived.

Before you commit, check the README's Laravel support matrix — the last release was July 2023 (likely Laravel 9/10), so verify it boots on your version.

Implementation Patterns

• Schema-aware seeding. Drive row generation from the live schema rather than maintaining factories in parallel. This is the whole value proposition — fewer files to keep in sync as migrations land.
• Column-level overrides. Always override sensitive or ambiguous columns: email, password, json, enum, money-as-integer, timestamps with business meaning. The synthesizer will happily guess wrong.
• Chunked generation. Don't request 100k users in a single call. Loop in 1k batches so memory stays flat and you can Ctrl-C without losing your DB.
• Compose with DatabaseSeeder. Call a dedicated SynthSeedUsers::class from DatabaseSeeder, guarded behind a --class flag or app()->isLocal() so CI and prod never trigger it.
• PII-free staging pipeline. Dump production schema only, seed locally with Synth, then promote the anonymized shape to staging. This is the cleanest use case for the package.
• Order of operations. Generate parents before children. Synth cannot infer cross-table relationships for you.

Gotchas and Tips

• Maintenance risk is real. ~275 stars, zero dependents, last release 2023-07-13, score ~2.2. Pin the version, vendor the source if you rely on it, and be ready to fork — MIT makes that legal.
• Placeholder README. The description literally reads "This is my package synth" — the original skeleton text. Expect thin docs and plan to read source for anything non-obvious.
• Type handling differs per driver. enum, json, uuid, and decimal columns are read very differently across MySQL / Postgres / SQLite. Smoke-test every column type on your actual target.
• Unique constraints. Synthetic names/emails will collide on large batches unless you override or supply a uniqueness strategy. You'll see duplicate-key errors mid-run and a half-seeded table.
• Debugging without persistence. Wrap generation in a DB::transaction() and rollBack() to inspect output locally. If the package exposes a dry-run/--pretend flag, use it — otherwise the transaction trick is the fastest loop.
• Fallback plan. If the package breaks on a Laravel upgrade, standard model factories + Faker fully cover the same ground. Treat Synth as a convenience layer over a pattern you already need, not an irreplaceable dependency.