Alice Bundle Laravel Package

Getting Started

First, confirm the stack. This is a Symfony bundle. It ships AliceBundle, a DependencyInjection extension, and console commands wired through the Symfony kernel. There is no Laravel service provider, no config/*.php, and no Eloquent persister. If you are in a Laravel codebase, stop and use Eloquent factories + fakerphp/faker instead — you cannot "just install" this. The rest of this assessment assumes a Symfony app (or that you are borrowing the approach, not the bundle).

Before install, read three things in the repo:

1. composer.json — the nelmio/alice and faker constraints. This fork has 0 stars / 0 dependents, so the composer constraints are your actual compatibility answer, not the README.
2. src/Resources/config/services.yml — reveals which Alice API generation it targets (Nelmio\Alice\Loader\* class names and signatures differ between v2 and v3).
3. src/AliceBundle.php + src/DependencyInjection/ — how fixture paths are discovered and which persister is expected (Doctrine ORM/ODM).

Minimal steps (Symfony):

composer require --dev madflow/alice-bundle

Register the bundle in config/bundles.php:

Madflow\AliceBundle\MadflowAliceBundle::class => ['dev' => true, 'test' => true],

Point it at a fixtures directory in config/packages/dev/madflow_alice.yaml (the config key is the bundle extension alias — check src/DependencyInjection/Configuration.php if it differs from the upstream hautelook_alice):

madflow_alice:
    fixtures_path: '%kernel.project_dir%/fixtures'
    db_drivers:
        orm: ~

First use case: create fixtures/users.yaml:

App\Entity\User:
    user_{1..10}:
        email: '<safeEmail()>'
        name: '<name()>'

Then check the actual command name with bin/console list | grep fixtures — forks frequently keep the upstream hautelook:fixtures:load namespace, sometimes rename it — and load:

bin/console hautelook:fixtures:load --env=dev

That is the whole loop: YAML in fixtures/, one command, Doctrine entities populated. If that does not work in under an hour, treat it as a signal to stop and evaluate the upstream hautelook/AliceBundle instead.

Implementation Patterns

Named references are the core value. Instead of instantiating related entities in PHP, you name them and reference the name:

App\Entity\User:
    admin:
        email: '[email protected]'
        roles: ['ROLE_ADMIN']

App\Entity\Post:
    post_{1..50}:
        author: '@admin'
        title: '<sentence()>'
        body: '<paragraphs(3, true)>'

This is where Alice beats hand-written factories once the relationship graph gets deep — explicit object wiring becomes brittle, while @admin references stay readable.

Volume with ranges, precision with explicit definitions. Use entity_{1..N} for bulk seed data and named singletons for records that tests assert against by identity. Mix both in one file.

Faker providers with locale. faker_locale (upstream config key) is your hook for locale-aware demo data. For anything domain-specific (SKUs, order numbers matching a regex), write a custom provider:

// src/Fixtures/Faker/OrderProvider.php
class OrderProvider extends \Faker\Provider\Base
{
    public function orderNumber(): string
    {
        return 'ORD-' . $this->generator->numerify('######');
    }
}

Register it via the bundle's provider config (again: confirm the key in Configuration.php; upstream uses faker_providers).

Command flags are your environment switch. The load command typically supports --append (add without purging), --purge (truncate first), and --env. Day-to-day:

• Local dev seed: --purge once, then --append as you iterate on fixtures.
• CI test database: fresh --purge load in a setUpBeforeClass or a Makefile target.

Wire it into the test lifecycle. Rather than invoking the command in every test, load fixtures once per test class (or use --append between tests with transaction rollback). A common pattern is a base KernelTestCase that boots a fresh database and loads a named fixture set.

Integration tip — do not mix concerns. Keep fixtures split by domain (fixtures/users.yaml, fixtures/orders.yaml) and include them from an entry file. Alice supports YAML include and template inheritance; use that instead of one 500-line file, which is impossible to review.

Gotchas and Tips

The fork is the biggest gotcha. 0 stars, 0 dependents, no maintenance signal. Before you commit to it:

• Diff composer.json against upstream hautelook/AliceBundle and establish exactly what the fork adds.
• Expect fzaninotto/faker (abandoned) rather than fakerphp/faker. On modern Symfony/PHP this will either force a downgrade or fail resolution outright. If it does, patch the constraint or vendor the fork and own it.
• Prefer upstream unless you have a documented reason. The YAML DSL is portable; the bundle wiring is not.

Entity hydration requires empty constructors and setters. Alice/Doctrine instantiates then populates. Entities with required-argument constructors or readonly properties will fail (or need __construct handling via Alice's __construct args). This is the #1 source of confusing hydration errors.

Fixture drift is silent. YAML definitions do not validate against your Doctrine schema. Rename a column or add a NOT NULL without default and you get a runtime failure at load time — often in CI long after the migration merged. Mitigate with a dedicated CI job that runs the full fixture load against a fresh schema on every PR.

Partial load state causes flaky suites. If a fixture load fails halfway, you get a half-populated database that poisons subsequent tests. Always run --purge in CI, or wrap the load in a transaction you can roll back. Never rely on a failed load leaving things "mostly OK."

Determinism. Faker is random by default. For tests that assert on generated values, seed the generator if the bundle exposes it, or assert on structure (count, relationship presence) rather than exact values. For demo data, randomness is fine; for tests, pin what matters.

Performance. Alice + Faker generating tens of thousands of records is CPU- and memory-bound, and Doctrine's unit of work adds per-entity overhead. Keep unit-test fixture sets small (tens of records); reserve the large full-seed for a single integration job. If you need big data, prefer direct SQL inserts for the bulk portion and Alice only for the interesting subset.

Command/config key names may not match upstream docs. The bundle class, extension alias, and command namespace in a fork are not guaranteed identical to hautelook/AliceBundle. When the docs don't match, read src/DependencyInjection/Configuration.php and the command class in src/Command/ — that is the source of truth.

Extension points worth knowing: custom Faker providers (for domain data), custom persisters (if you need something other than Doctrine's), and Alice's Processor interface for per-object mutation after instantiation. Those are the seams where you can adapt the bundle without forking further.

Bus factor. Likely one person on the team understands the YAML DSL and Symfony bundle conventions. Document your fixture layout, the command invocations, and the custom providers in the repo README — otherwise onboarding cost quietly exceeds the toil it saves. If you decide the trade isn't worth it, the honest fallback is Symfony's doctrine-fixtures-bundle with plain PHP fixture classes; less expressive, far more debuggable.