Options For Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy for package internals: If we maintain or consume a Laravel package whose models are meant to be swappable by the host application, this release removes the need to write bespoke factory glue. Adopt rather than hand-roll per-project factory overrides.
• Extensibility roadmap: Confirms the package treats model swapping as a first-class, supported pattern. That supports roadmap items like "let enterprise customers substitute their own User/Tenant/Invoice models without forking."
• Feature scoping: The fix is confined to test/factory ergonomics — it does not add runtime capabilities. Treat it as a quality/maintenance signal, not as a feature we can market on its own.
• Release cadence judgment: A patch-level fix (1.1.2) landing shortly after 1.1.x indicates active maintenance. Useful input when deciding whether to depend on this package long-term vs. pinning and monitoring.
• QA and onboarding cost: Host apps that swap models no longer need custom test factories or per-project fixture code, which reduces integration effort for downstream teams and shortens onboarding for new consumers.
• Use cases unlocked: Multi-tenant apps overriding the tenant model, white-label deployments overriding branding/content models, and internal platforms where a shared package serves several product lines with different model classes.

When to Consider This Package

Adopt when:

• You maintain a Laravel package (or a shared internal library) that exposes model classes through config or a container binding, and you expect host apps to substitute them.
• You want factories and test fixtures to follow the configured model automatically, so swapping a model doesn't silently break seeders, tests, or demo data.
• Your consumers are themselves developers who will customize models — the value compounds with each host app.
• You are already standardizing on Laravel's factory conventions and don't want a parallel fixture layer.

Look elsewhere or skip when:

• Your models are fixed and never swapped — the benefit is inert, and a plain Laravel factory is sufficient.
• You need runtime features (routing, validation, admin UI) rather than test-time plumbing; this release adds none.
• You require a stable, long-supported API surface: this is a small patch fix, and a single-line changelog gives limited insight into the package's broader stability, test coverage, or maintainer bandwidth. Validate those before committing.
• You need documented upgrade guarantees — verify the changelog history and semver discipline first; a thin release note is not evidence of policy.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk maintenance release for a Laravel package that supports swapping data models per deployment. It fixes a bug where test fixtures ignored a customer's substituted model. The practical effect is fewer custom-code workarounds in customer-specific deployments and lower integration cost — no new product capability and no migration required.

For engineering: Version 1.1.2 patches factory resolution so that when a host application rebinds a model (via config or container swap), factories build that configured class instead of the package default. It is a patch-level change: no breaking API changes, no deprecations, no new configuration surfaced. Safe to take as a routine dependency bump. Engineers should confirm their swap mechanism (config key vs. container binding) is the one covered, and add a regression test asserting the factory returns the host's model class — that test is the durable guarantee this release is meant to provide.

Recommendation: Adopt as a routine upgrade. Do not treat it as a launch-worthy item; do use it as a prompt to add the regression test and to confirm the package's maintenance trajectory before deepening the dependency.