Refresh Tokens For Laravel Laravel Package

Product Decisions This Supports

• Extensibility strategy — do we let hosts override our domain models, or force a fork? The fix confirms the package supports config-driven model substitution and that its factories honour the swap. That makes "extend, don't fork" a viable product decision for anything built on top of it: host apps can ship their own Eloquent model and still get working test fixtures, seeders, and demo data.
• Build vs buy for commodity domain primitives. A package that explicitly accommodates model swapping is signalling it expects to be embedded in someone else's domain, not to own it. That lowers the long-term cost of adoption (no vendored fork to maintain), which is the main hidden cost in build-vs-buy comparisons of this type.
• Roadmap / upgrade risk budgeting. This is a patch-level correctness fix in a 1.1.x line: no API changes, no schema changes, no migration. It can be absorbed in a routine dependency refresh rather than scheduled as work. Treat it as a "safe to take now" item.
• Test-infrastructure quality. Any roadmap item that depends on seeded/demo environments (QA environments, sales demos, onboarding fixtures, multi-tenant provisioning) benefits: fixtures now reflect the actual configured model, so environment-specific breakage surfaces in CI instead of in a demo.
• Use cases where this matters most: multi-tenant or white-label deployments where each tenant/host supplies its own model class; plugin or module architectures; teams whose test suites lean on factories for realistic data.

When to Consider This Package

Consider it when:

• You are adopting (or already run) a Laravel app that needs this capability and you want the option to substitute your own model class without losing factory support — this release specifically de-risks that path.
• Your test suite or seeders depend on factories and your configuration swaps models; before 1.1.3 that combination could produce fixtures for the wrong class, i.e. silently passing tests against a model you don't actually ship.
• You value a maintainer who fixes host-integration edge cases at patch level rather than deferring them to a minor release — a reasonable proxy for maintenance responsiveness.
• You can pin versions and take patch updates on a normal cadence.

Look elsewhere when:

• You do not swap models. The fix is a no-op for you; it is not a reason to adopt, and the release tells you nothing new about feature depth, performance, or security.
• You need contractual stability or LTS guarantees. A 1.1.x patch on model resolution is a good sign, not a guarantee; there is no evidence here about the project's long-term support posture, release cadence, or governance.
• You need production-scale or security assurance. Nothing in this release speaks to either. Evaluate separately.
• Your decision hinges on capability breadth. One patch note about factories is thin evidence. The confidence in this assessment is deliberately low on anything beyond "the package anticipates host model substitution and fixes regressions in it"; do not treat it as a substitute for a spike or a review of the package's docs and issue history.
• You need framework-version or PHP-version compatibility commitments — not established by this release.

How to Pitch It (Stakeholders)

For executives (one line): A small, low-risk maintenance release in a dependency we use — it corrects test-fixture generation for teams that customise models. No roadmap impact, no migration, no customer-visible change; take it at the next routine dependency refresh.

For engineering: Version 1.1.3 fixes factories so they build the configured model when a host application swaps it, rather than resolving to the package's own concrete class. If your app overrides the model via config, your factory-backed tests were previously able to pass against the wrong class — this closes that false-positive. Action: bump the dev dependency, run the factory/seed suite, and spot-check any seeder that assumes the package default model. No config or data changes expected. Worth flagging that any test which starts failing after the bump was likely asserting against the wrong model — investigate rather than reverting.