- What does mpociot/laravel-test-factory-helper actually do?
- It is a dev-only Artisan generator that inspects your Eloquent models and database schema via Doctrine DBAL, then writes Laravel factory definitions with Faker mappings per column type. It targets the legacy $factory->define DSL, so it is useful for quickly bootstrapping test fixtures in Laravel 5.x–7.x projects. Review the generated files before committing them because inference is not perfect.
- Does it work with Laravel 8, 9, 10, and 11?
- No. The package emits the legacy $factory->define syntax, while Laravel 8 introduced class-based factories in Database\Factories and Laravel 9 removed the legacy layer entirely. Generated output will not load on modern Laravel without deprecated compatibility packages. Use Laravel's native make:factory --model generator on Laravel 8 and above.
- How do I install mpociot/laravel-test-factory-helper?
- Install it as a dev dependency with composer require --dev mpociot/laravel-test-factory-helper. It requires doctrine/dbal, so pin both packages explicitly and test composer update in a throwaway branch before touching a real repository. Expect dependency resolution friction on PHP 8.x and Laravel 8+.
- Why does it conflict with doctrine/dbal on modern PHP or Laravel?
- doctrine/dbal is a hard requirement, and its PHP and Laravel version matrix has historically collided with Laravel 8+ and PHP 8.x. You may see install failures or need --ignore-platform-reqs workarounds that you should not apply casually. This is install-time incompatibility rather than runtime breakage, so avoid the package on modern stacks.
- Is it safe to deploy or use in production?
- It is a development-only Artisan generator with no runtime dependency, so it should never reach a deploy artifact. Confirm production builds run composer install --no-dev and that the require-dev entry is removed once you have harvested the generated factories. The blast radius is wasted developer time, not a production incident.
- What column types does it handle, and what about JSON, enum, uuid, or geometry?
- It maps common column types to Faker providers, but column types it does not understand can produce silent misgeneration such as nonsense fixtures for json, enum, uuid, geometry, or encrypted casts. The output may compile while being semantically wrong. Have an engineer review every generated factory against actual model casts, relationships, and schema constraints.
- Is this package still maintained?
- No. There has been no release since March 2020 and no maintainer activity since then, so assume upstream is closed. The source is small and forkable, but there is no downstream ecosystem pressure to fix it. Treat it as a one-shot legacy tool, not a long-lived stack component.
- What should I use instead for Laravel 8 and newer?
- Use the framework's native php artisan make:factory --model generator plus a small house style guide. You accept slightly less schema-aware inference in exchange for zero dependency risk and full framework support. For legacy Laravel 5.x–7.x apps, this package can still save time if you review the output carefully.
- What is the recommended workflow for using it in a legacy app?
- Pilot it against one low-risk legacy app with five to ten representative models. Run the generator, then have an engineer review every emitted factory against real casts and relationships, fixing or hand-writing gaps for relationships, enums, and JSON. Commit the generated code and drop the require-dev entry in the same PR, then document the pattern so nobody re-adds it.
- Can I use it as a repeatable CI step or ongoing dependency?
- No, it is best treated as one-shot scaffolding that you commit and review. Leaving it in composer.json creates an orphaned dev dependency that will break on the next PHP or Laravel bump with nobody owning the fix. Generate once, harvest the output, and remove the dependency from the project.