Factory Laravel Package

Technical Evaluation

Architecture fit. aerni/factory is a Statamic addon that ports the Laravel model-factory pattern to Statamic collections and entries: you declare a factory class describing field values, and it produces fake entries via Faker. Architecturally it sits in the content-authoring layer, not the request path — it depends on Statamic's entry/collection APIs and Laravel's container and Faker, and produces no runtime services, middleware, or routes on the front end. That makes it a natural fit for teams already modeling content as code (collections, blueprints, field sets in version control) where seed and demo content is the missing piece. It is a poor fit for teams that treat content as editorial-only and stage it manually.

Integration feasibility. Low-friction. It is a Composer package installed with --dev, has no published service providers that must run in production, and no database schema of its own. Integration effort is dominated not by installation but by authoring factories — one per collection/blueprint, which is real work proportional to content-model complexity (Bard/Replicator/Grid nesting, asset and term relations, multisite locales).

Technical risk. Concentrated in project maturity, not in technical surface area:

• Bus factor of one. Single maintainer, ~19 stars, zero dependents. There is no downstream corpus to absorb a breakage.
• Version coupling — partially de-risked as of v1.5.1. The latest patch release updates stillat/primitives specifically to restore Statamic 5 compatibility, which is direct evidence the package is being maintained against the current Statamic major and that the maintainer treats compatibility breakage as a fix-worthy defect. That is a meaningful positive signal and moves Statamic 5 from "assumed supported" to "supported in practice." It does not, however, establish a forward commitment to Statamic 6. Field-type coverage (Bard, Replicator, Grid, assets, links) remains the most likely breakage point, since those APIs are the least stable part of Statamic.
• Transitive dependency exposure. The fix landed in a dependency (stillat/primitives), not in the addon itself. Compatibility is therefore a function of a chain we do not control directly, and a future Statamic release may require waiting on an upstream primitive update before the addon can follow. Worth capturing in the dependency review alongside the addon itself.
• Identity ambiguity. Package name (aerni/factory) differs from repository name (statamic-factory), a minor supply-chain hygiene flag worth noting in a dependency review.
• Blast radius is small. Because usage is dev/test-only, the realistic worst case is "seeding breaks after an upgrade," not a production incident. This should drive the risk appetite.

Key questions. (1) Which Statamic and Laravel versions are we targeting, and is that combination explicitly supported? Largely answered: Statamic 5 is targeted and supported as of v1.5.1. Narrow the remaining question to our specific Laravel/PHP version combination and whether Statamic 6 is on the maintainer's roadmap. (2) Does it cover the field types in our blueprints — specifically Bard, Replicator, Grid, assets, and entries relations? (3) Does it handle multisite/localized entries if we run sites? (4) How do we generate deterministic, referentially consistent content (e.g., entries that reference real asset containers) rather than random values? (5) Who owns the factories, and are they checked in? (6) What is our exit cost if the package is abandoned — days or weeks? (7) New: what is our policy when a Statamic upgrade requires an upstream stillat/primitives fix — do we wait, pin, or fall back to the seeder?

Integration Approach

Stack fit. Requires a Laravel + Statamic application; assumes Composer, PHP 8.x, and Faker. It fits cleanly alongside existing tooling (php artisan, Pest/PHPUnit, CI) because generated entries are ordinary Statamic content that the rest of the stack already knows how to read.

Migration path. Not a migration in the traditional sense — it is additive. Start by installing as a dev dependency in a branch on v1.5.1 or later (earlier versions should be considered Statamic 5-incompatible until proven otherwise — this is exactly the class of breakage the patch addresses), author a single factory for one low-risk collection, and generate content into a local or ephemeral environment. Compare output against the manual seed data it would replace. Expand coverage collection-by-collection. Critically, keep a documented fallback: a hand-rolled Faker seeder using Statamic's entry API is a few hundred lines and is the de facto escape hatch if the package is retired.

Compatibility. Pin the package version explicitly (^1.5.1 at minimum) and validate against our Statamic and Laravel versions in CI before relying on it. Because the recent fix was transitive, include stillat/primitives in the lockfile review and confirm the resolved version is the one that carries the Statamic 5 fix — a stale lockfile could silently reintroduce the incompatibility. Treat the Statamic major upgrade as a gate requiring a factory regression run. Verify Faker major-version alignment (Faker v1 vs v2 differ in API), since the addon's dependency constraint may pin us indirectly.

Sequencing.

1. Spike (1–2 days): install v1.5.1, generate one collection, confirm field-type coverage against a representative blueprint.
2. Pilot (1 sprint): factories for the two or three collections used in demos/QA; wire into a CI or demo-environment seeding job.
3. Standardize: document factory conventions, check factories into the repo, add a smoke test that seeds and asserts entry count and required fields.
4. Decide on scope: restrict to local/dev/CI environments; explicitly exclude production seeding.

Operational Impact

Maintenance. Near-zero steady-state cost if the content model is stable; non-trivial churn if blueprints change often, since factories must be updated in lockstep with field additions. Budget factory maintenance as part of content-model change work, not as infrastructure work. Add a small recurring cost: a dependency-version check on each Statamic upgrade cycle, watching both the addon and its stillat/primitives transitive.

Support. Community-only: GitHub issues on a low-traffic repository with a single maintainer. No SLA, no paid support, no commercial backer. The v1.5.1 release shows the maintainer is responsive to compatibility breakage, which is reassuring but is still not a support commitment. Internal ownership must be assigned — realistically one or two engineers who know the package and can maintain the fallback seeder.

Scaling. Content generation is I/O-bound on Statamic's entry writes and Stache index updates. It is fine for tens to low thousands of entries; large batches need chunking and may hit memory limits or slow Stache rebuilds. It is not a load-testing tool and should not be repurposed as one.

Failure modes.

• Statamic upgrade breaks field-type support → factories throw; contained to dev/CI. The v1.5.1 patch demonstrates the recovery path exists but also that recovery is dependency-mediated and may lag the Statamic release.
• Stale lockfile after a Statamic upgrade → resolves an older stillat/primitives and reintroduces the exact incompatibility v1.5.1 fixes. Mitigate with a lockfile diff in the upgrade PR checklist.
• Slug/title collisions on regeneration → duplicate or overwritten content; mitigate with deterministic seeds and a clean-slate teardown step.
• Inconsistent relations (entries pointing at nothing, missing assets) → misleading demo environments; mitigate with ordered factory execution and referential fixtures.
• Accidental execution against a non-local environment → real data pollution. This is the highest-severity failure and is entirely preventable with environment guards and an explicit --env check.
• Package abandonment → frozen dependency; exit cost is the fallback seeder, so keep factories written against Statamic APIs rather than package-specific abstractions where practical.

Ramp-up. Low for anyone fluent in Laravel factories — the mental model transfers directly. Estimate half a day to productivity, plus blueprint-specific learning for Bard/Replicator nesting, which is where most of the real effort lands. Documentation should be an internal README covering factory conventions, environment guards, the pinned-version rationale, and the fallback procedure, not a link to the upstream repo alone.