Legacy Factories Laravel Package

Product Decisions This Supports

• Sequencing the framework upgrade ahead of test-infrastructure modernization. This package lets you decouple two epics that are usually bundled: "get onto a supported Laravel/PHP version" and "convert closure factories to class-based factories." That's the core product decision it enables — you can ship the upgrade on the roadmap this quarter and schedule the factory refactor as separately estimated, separately prioritized debt.
• Roadmap: unblocking a security/packages deadline. If the app is pinned to Laravel ≤7, you're also pinned on PHP versions, security patches, and every third-party package that drops old Laravel support. This package removes factory syntax as a blocker, which is often the largest single line item in an upgrade estimate.
• Scope reduction in upgrade estimates. Instead of "upgrade + rewrite N factories + re-baseline all test fixtures," the estimate becomes "upgrade + add one dev dependency + verify suite." Engineering effort shifts from mechanical rewriting to validation, which is cheaper and lower-variance to plan against.
• Build vs. buy: buy, and specifically buy first-party. It is an official Laravel-maintained MIT package with a one-line release per Laravel major (9, 10, 11, 12, 13 all tracked). Building an in-house shim would replicate this for no benefit and would be your maintenance burden at every future framework bump.
• Use cases that justify adoption: phased monolith upgrades; apps with large legacy test suites or seeders calling the factory() helper; apps depending on legacy third-party packages whose service providers or tests still invoke factory(); acquisitions/inherited codebases where you need CI green before you can safely refactor.
• Risk containment is a product argument, not just a technical one. This is a require-dev dependency. It does not ship to production, does not alter runtime behavior, and cannot affect customers. Its blast radius is limited to test and seed data. That materially lowers the approval cost of adopting it.
• It also creates a decision you must make explicitly: the package is a bridge, not a destination. Adopting it without a dated removal milestone converts a one-time upgrade cost into a permanent two-paradigm tax (dual fixture conventions, onboarding confusion, inconsistent test data shapes). Treat "schedule removal" as part of the same decision, not a follow-up.

When to Consider This Package

Adopt when:

• You are upgrading a Laravel ≤7 app to 8+ and have existing closure-based factories ($factory->define(...)) in database/factories/.
• Seeders or tests widely call factory(Model::class)->create() and rewriting them is not on the current critical path.
• You've inherited a codebase or dependency whose legacy packages still rely on the factory() helper.
• You have a working CI suite — you need it to validate the shim before you trust it, and you need it to prove parity during the upgrade.
• You can name an owner and a target date for removing it.

Look elsewhere / skip when:

• Greenfield project — use native class-based factories from day one; there is no legacy surface to preserve.
• You're already on Laravel 8+ with class-based factories. Adding this reintroduces a deprecated API for zero benefit.
• The factory footprint is small. Run the numbers first: if it's a handful of factories, a direct one-time refactor is likely fewer engineer-hours than adopting a dependency, governing dual conventions, and then removing it. Adoption has a fixed overhead; below a certain size it doesn't pay back.
• Nobody can commit to a removal date, or the team lacks CI coverage to verify the shim behaves identically. In that case you're purchasing indefinite dual-paradigm cost to avoid a bounded refactor — a bad trade.
• You need modern factory capabilities (relationships via for()/has(), asJSON(), async/queue-aware creation, state classes). This package restores only the legacy API and deliberately does not bridge to the new one; you cannot share definitions across both styles.

Governance to attach at adoption: a written convention that no new legacy factories may be added (enforceable in review or lint), a tracked ticket for removal, and a rule that each touched model migrates to a class-based factory opportunistically.

How to Pitch It (Stakeholders)

For executives (one paragraph): We're behind on a supported Laravel version, which means no security patches and an increasing number of libraries we can't take. Most of the upgrade work is mechanical, but the factory syntax change is the piece that forces every test and seeder to be rewritten at the same time. Laravel publishes an official, MIT-licensed compatibility package that makes the old syntax keep working, so we can complete the upgrade now and modernize the tests on a planned schedule instead of blocking the release. It's a development-only dependency: nothing about it ships to customers or changes production behavior, and the worst case is that tests fail in CI — which we'd catch before merge. The tradeoff is a temporary period where two factory styles coexist, so we're committing to a removal date and a rule that no new legacy factories get written.

For engineering: One-line install as a dev dependency, auto-discovered, no core changes, no production code path. It restores the factory() helper and legacy closure definitions so existing tests and seeders run unchanged on Laravel 8 through 13. It is first-party and has shipped a release for every Laravel major, which is the maintenance signal that matters here. Constraints to plan around: it restores only the legacy API — no for()/has()/asJSON(), no shared definitions between old and new styles; and mixed codebases need a convention so contributors don't guess which style to use. Recommended path: install, run the full suite to confirm parity, migrate factories opportunistically as models are touched, and close out the dependency by a set date. If factory() comes back undefined, it's autoload/package-discovery, not a package bug.