Sluggable For Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy for the data layer: The package exposes a configuration-driven model layer that hosts can swap out. This is an extension point most teams would otherwise hand-roll, so it weighs on the "buy/adopt" side of the ledger — adopting it buys a customization contract instead of a fork.
• Multi-tenant and white-label roadmap: Model swapping via configuration (rather than code edits) is the mechanism that makes per-tenant or per-brand data models viable. This release confirms factories respect that swap, which is the prerequisite for testing tenant variants at scale.
• Test-suite investment and CI confidence: Factories that build the configured model mean host applications can swap a model and still get accurate fixtures. This reduces the risk of false-green test suites — a hidden cost that usually surfaces late in a release cycle.
• Upgrade cadence / maintenance risk: A 1.1.3 patch with a narrow, well-scoped fix signals active maintenance and a disciplined semantic-versioning posture. Patch-level changes are low-risk to absorb, so this does not need to be scheduled against a release freeze.
• Extensibility positioning against alternatives: If we evaluate competing packages, "can I replace the model without forking?" becomes a concrete, testable criterion rather than a vague one.
• Documentation and onboarding scope: Because the swap mechanism is configuration-based, onboarding cost is mostly config and factory conventions — worth budgeting a short internal note for engineers rather than a full integration project.

When to Consider This Package

Consider adoption when:

• We need to customize or replace the package's models — extra columns, relationships, or domain-specific behavior — without patching vendor code.
• We run multiple host applications, tenants, or brands off a shared codebase and need per-context model resolution.
• Our test strategy depends on model factories, and we need fixtures to reflect the swapped model rather than the package default (the exact gap closed in 1.1.3).
• We want an extension contract that is configuration-first and low-ceremony, rather than a service-provider binding framework we have to design ourselves.
• We are on a 1.1.x-compatible Laravel/PHP baseline and can take patch upgrades on a normal cadence.

Look elsewhere when:

• We need no model customization at all — the swap machinery adds surface area and config we will never exercise.
• The domain requires schema-level control (migrations, indices, cross-database support) that a config swap cannot express; a first-party implementation may be cleaner.
• We require long-term support guarantees, deprecation policy, or vendor SLAs — a 1.x community package with patch-only maintenance history does not provide those.
• Our team is unfamiliar with Laravel service container and config publishing conventions; the benefit depends on engineers understanding the swap contract.

How to Pitch It (Stakeholders)

For executives: This is a small, actively maintained Laravel package that lets us customize the data models it provides through configuration instead of forking vendor code. The 1.1.3 release is a bug fix — when we substitute our own model, the package's test factories now build our model rather than the default. That matters because it keeps our automated tests honest in multi-tenant and white-label scenarios, which is where forks usually become expensive. It is a patch release: no breaking changes, no migration work, no roadmap impact.

For engineering: The package resolves models through configuration, and 1.1.3 makes factory resolution consistent with that contract — factories now instantiate the configured model class when a host swaps it. Practical effect: our factories and seeders stay valid after a model swap, so we avoid maintaining parallel factory definitions or tolerating silently incorrect fixtures. Upgrade is a routine composer update on the 1.1 line; validate by swapping a model in a test and asserting the factory returns the swapped class. Recommendation: adopt the swap pattern as our standard extension route, document it in the internal conventions note, and avoid forking.