Forms For Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy on extensibility: The package's core value is that a consuming "host" application can substitute its own model class for the package default. That is the difference between shipping a closed feature and shipping a feature downstream teams can adopt without forking. If extensibility is on your roadmap, this is a credible off-the-shelf primitive rather than hand-rolled config plumbing.
• White-label / multi-tenant go-to-market: Swappable models are the mechanism that lets one codebase serve customers with divergent domain models. Factory fidelity (release 1.0.4) is what keeps that promise honest outside of production — seeders, demos, and test suites now exercise the customer's model, not the vendor default.
• Feature scoping and support-cost modeling: Every configurable surface is a support surface. This release reduces a class of "my factories create the wrong model / my tests pass but my app doesn't" tickets that otherwise land on engineering and erode trust in the integration path. Factor that reduction into the cost of offering customization at all.
• Integration risk in the sales/onboarding motion: Because the fix restores expected behaviour rather than changing it, it is safe to recommend to prospects mid-evaluation — no migration, no config change, no version pinning gymnastics.
• Roadmap signal: A 1.0.x line still receiving correctness fixes suggests active maintenance but also that the extensibility contract is young. Treat deeper bets (making model swapping a documented, public, supported contract) as contingent on the maintainer's responsiveness over the next few releases.

When to Consider This Package

Adopt when:

• You distribute a Laravel package or a shared application core that other teams embed, and you expect them to want their own model classes.
• You have (or plan) tenant- or customer-specific domain models and want factories and seeders to follow the configured model automatically.
• Your team relies on configuration-driven resolution rather than service-container rebinding for model substitution, and you want that path tested for you.
• You are comfortable with a small, single-maintainer dependency and can pin a version.

Look elsewhere when:

• You operate a single application with no model substitution requirement — Laravel's container and Model::resolveRelationUsing-style tooling already covers most of this, and the added indirection is pure overhead.
• You need a formally supported public API contract, an SLA, a security review trail, or long-term support commitments. A 1.0.4 patch note is not that evidence.
• Your substitution needs extend beyond models (repositories, services, whole-domain swaps); a broader container-swapping or modular architecture is the better fit.
• You cannot test the swap path yourself. The fix is only valuable if you verify it against your swapped model in your test suite before committing to the integration.

How to Pitch It (Stakeholders)

For executives: This is a small dependency that makes our product customizable per customer without forking the codebase. The latest patch fixes a defect where test data and demo seeding would silently use our default model even when a customer had configured their own — the kind of bug that surfaces as a broken demo or a failing customer test suite rather than an obvious error. It is a low-risk, no-migration update that lowers integration and support cost. The trade-off is a young, small-maintainer dependency; we should pin the version and keep an exit path.

For engineering: The package provides a configuration-driven model swap for host applications, and 1.0.4 makes factories build the configured model rather than the default one. That closes the gap between "the app resolves the swapped model at runtime" and "our factories and seeders agree," which is where most silent test-fixture bugs come from. No breaking changes, no deprecations, no config changes — the default path is untouched for anyone not swapping. Before adopting, add one test in our suite that swaps the model and asserts a factory-produced instance is of the swapped class; if that passes, the integration is sound.