Lendo Fixtures Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package — the first thing to internalize is that php artisan will not pick it up. If you're working in a Lendo project, you're on Symfony; if you're trying to use it from Laravel, you need a bridge (see Gotchas).

1. Install from the private source. Zero stars and zero dependents means this is an internal Lendo artifact, almost certainly published on a private Composer registry or referenced via a VCS repository. Expect to need credentials:

   composer config repositories.lendo-fixtures vcs [email protected]:LendoSTPGdansk/lendo-fixtures-bundle.git
   composer require lendo-stp-gdansk/lendo-fixtures-bundle:^1.0 --dev
   

   Pin a version rather than dev-master; there is no community to catch a broken tag.

2. Register the bundle in config/bundles.php (Symfony Flex may do this for you if the recipe is private):

   Lendo\FixturesBundle\LendoFixturesBundle::class => ['dev' => true, 'test' => true],
   

   Keeping it out of prod is the single most important configuration decision here.

3. Find the entry points — read these files first, in order:

   • src/DependencyInjection/Configuration.php and *Extension.php — this tells you the config tree (lendo_fixtures: keys), default fixture paths, and the service tag name.
   • src/Command/ — the actual console commands and their options. This is your day-to-day interface.
   • The fixtures engine class (usually src/Fixtures/…Engine or Loader) — this defines the execution order and the contract your fixture classes must satisfy.
   • README.md — likely thin, treat code as the source of truth.

4. Confirm it's wired up:

   bin/console list lendo
   bin/console debug:container --tag=<fixture tag from the extension>
   

   If the tag returns nothing, your fixtures aren't being collected and nothing will run — that's the #1 "it silently does nothing" failure.

5. First use case: local dev / CI database seeding for a Lendo domain project (customers, applications, offers, statuses). Write one fixture class for the smallest meaningful aggregate, load it against a throwaway SQLite/MySQL schema, and verify the command output before touching a shared environment.

Implementation Patterns

Write fixtures as tagged services, not as scripts. The bundle collects them via a compiler pass, so a fixture is just a class implementing the bundle's fixture interface, registered in config/services.yaml under the tag the extension declares:

services:
    App\Fixtures\:
        resource: '../src/Fixtures/*'
        tags: ['lendo.fixtures.fixture']   # verify exact tag name in the Extension

Use autoconfigure: true on the _defaults block if the interface is used for autoconfiguration — that removes the manual tag entirely and is the cleaner long-term setup.

Express load order explicitly. Almost every fixtures engine either supports a priority attribute or a getDependencies() method. Prefer dependency declarations over priorities: priorities are invisible and reorder silently when someone adds a fixture in the middle. If the bundle only supports priority, keep a documented convention (e.g. 100 = reference data, 50 = tenants/users, 10 = transactional data).

Keep fixture sets separate and named. Don't build one monolith. Provide a minimal set (base), a demo set (demo), and a performance set (bulk), and select via the command's option (typically --group= or a fixture-name filter). Wire the sets as separate tagged services or via config so CI and local dev pull different slices:

# config/packages/dev/lendo_fixtures.yaml
lendo_fixtures:
    paths: ['%kernel.project_dir%/fixtures']
    # any purge/truncate behaviour flag belongs here, and only here

Make fixtures idempotent where possible. If the engine supports append mode, design fixtures to look up-or-create by a natural key (external reference, email, slug) rather than assuming an empty table. This makes re-runs after a partial failure cheap. Reserve destructive "purge then load" behaviour for CI and never for shared staging.

Share references between fixtures via the bundle's reference store. If the engine exposes a reference repository (the Doctrine Data Fixtures addReference/getReference pattern is the common one), use it instead of hardcoding IDs. Hardcoded IDs are the most common source of "works on my machine" fixture failures.

Use it in CI as a schema-checking tool, not just a seeder. A useful pattern: in the pipeline, boot the test database, purge, load the base set, and run the suite against it. This catches entity mapping regressions that unit tests miss, because fixtures exercise every association.

Laravel-side integration, if you must. There is no service provider, no facade, no artisan command. Two realistic options:

• Wrap it: write a Laravel service provider that registers the engine's services and re-exposes the command as an Artisan command delegating to the bundle's execute(). Doable only if the bundle has no hard Symfony kernel/framework coupling — check composer.json for symfony/framework-bundle and symfony/console requirements.
• Port the fixture classes: keep them as plain PHP, drop the bundle, and drive them from a standard db:seed seeder. For a package with zero dependents, this is often less work than maintaining a bridge.

Compose with doctrine/data-fixtures where possible. If this bundle is a thin orchestration layer over Doctrine's fixtures, your fixture classes are likely interchangeable with plain Doctrine ones — that keeps you from being locked in.

Gotchas and Tips

• Environment guard is mandatory. A command whose default behaviour is "purge and reload" will happily destroy staging. Register the bundle only in dev/test in config/bundles.php and put an explicit kernel.environment check in your deploy scripts. Belt and braces.
• Silent no-op. If fixtures don't run, check the container tag first: bin/console debug:container --tag=<tag>. A missing tag, a wrong namespace in the resource: glob, or a class that doesn't implement the interface all fail without an error.
• Zero dependents / zero stars means zero safety net. No Stack Overflow answers, no upstream issue triage you can rely on, likely no tagged releases. Pin to a commit SHA or exact version, vendor it if it's small, and read the diff of any update. Budget for the possibility that you fork it.
• Ordering cycles. If dependencies are declared and two fixtures reference each other, the engine will either loop forever or silently drop one. Keep dependency graphs shallow and one-directional (reference → aggregate → transactional).
• Determinism. Seed Faker (or whatever generator the engine uses) explicitly. Unseeded randomness makes flaky tests and unreproducible bug reports; it's a one-line fix that people forget.
• Performance. Loading thousands of rows through the ORM is slow. Look for engine hooks to flush in batches, and disable SQL logging and Doctrine lifecycle listeners for the load command in dev. If the bundle exposes a --no-debug-style flag, use it.
• Transactions and multi-entity-manager setups. A transaction around the whole run only works if all fixtures share one connection/EM. With multiple managers, a mid-run failure leaves partial data — hence the idempotency advice above.
• Debugging a fixture: run the command with -vvv, and if you need finer detail, temporarily wrap the engine call in your own command so you can dump() between fixtures. Black-box debugging through a bundle command is slow.
• Extension points worth knowing: the tagged-service contract (add your own fixtures), the config tree (paths, groups, purge flags), and — if present — a loader/profiler interface. Before writing workarounds, check src/DependencyInjection/ for a compiler pass you can hook into; internal bundles often have more exposed surface than the README suggests.
• Treat it as infrastructure, not a dependency. Because it touches your database destructively, add a smoke test in your own repo that runs the load against a scratch DB. You are the maintainer of your own safety here.