Laravel Sluggable Laravel Package

Product Decisions This Supports

• URL / content architecture (SEO & schema constraints): The package lets you cap slug length (slugsShouldBeNoLongerThan) while still guaranteeing uniqueness via suffixes. That makes it a direct input into decisions like "do we shorten slugs for SEO/readability" versus "do we size the DB column to fit suffix growth." v1.0.2 makes the failure mode of a too-tight cap explicit (InvalidOption) instead of silently writing an overlong slug — so the constraint becomes a designed, testable rule rather than a data-quality landmine.
• Build vs. buy for a commodity capability: Slugs are not a differentiator; buying is the default. The differentiator here is the eject path (sluggable:eject), which lets you adopt now and own the code later. That materially lowers the switching cost of the "buy" decision and de-risks the roadmap item "what happens if this package is abandoned or diverges from our needs."
• Adoption posture for scaffolding/generation features: v1.0.2 makes eject atomic — all files are staged to a temp location and only moved on full success. This turns eject from a "risky, do-it-manually-on-a-clean-branch operation" into something safe to run in scripted environments. That supports decisions to standardize onboarding/bootstrap scripts and to use eject as part of a documented graduation runbook.
• Upgrade sequencing / release policy: v1.0.2 is versioned as a patch but contains a behavioral change (silent overrun → thrown InvalidOption). This is a decision input: treat it as minor-level risk in your upgrade plan, and audit any environment where the configured max length is shorter than, or near, the generated suffix length (e.g., limit 1 with suffix -1).
• Reliability posture for write operations: The atomicity fix is a signal about maintainer priorities — correctness and no-partial-state over convenience. Useful when justifying continued investment or when arguing for pinning/upgrading to the latest patch in production.

When to Consider This Package

Adopt when:

• You generate human-readable, unique slugs for user- or CMS-authored content and need deterministic uniqueness with suffixes, not just a one-shot Str::slug() call.
• You have a hard length ceiling (DB column width, legacy schema, SEO guidance) and want that ceiling enforced rather than hoped for. The new InvalidOption behavior is a feature here: misconfiguration fails fast at the point of slugging instead of producing silently truncated/overlong data.
• Code ownership and exit strategy matter. If your org has a policy against long-term dependency on small packages, the eject command is the deciding factor: you can ship on the package and, if needed, materialize the implementation into your codebase in one atomic, all-or-nothing step.
• You run scaffolding or environment setup in CI or automated scripts — atomic eject removes the "half-ejected app" failure mode that would otherwise poison a build or a fresh environment.
• You are standardizing slug behavior across multiple Laravel services and want one consistent, configurable policy rather than N bespoke implementations.

Look elsewhere / defer when:

• You cannot change configuration in an existing app and currently rely on the old lenient behavior (overlong slugs written silently). Upgrading will surface InvalidOption at runtime for those inputs; if you can't audit and adjust slugsShouldBeNoLongerThan / suffix config, stay pinned and plan the migration deliberately.
• You need concurrency-safe uniqueness at high write throughput. App-level "check then append suffix" logic can race under parallel writes; pair this with a DB unique index and retry, or choose a DB-enforced approach.
• You need capabilities this release doesn't speak to — heavy multilingual transliteration, per-locale slug routing, or slug history/redirect management. Those are separate product decisions; don't assume this package covers them.
• You are not on Laravel, or you need a framework-agnostic library.
• You want a vendor with SLAs and support contracts; this reads as a small, single-maintainer package — acceptable for a commodity concern, not for a critical path you can't eject from.

Risk notes to carry into the decision: the thrown InvalidOption is the kind of change that appears in production rather than in tests, because it depends on runtime config plus actual content (long titles, numeric-only titles, non-Latin scripts producing short bases). Add a slug-generation regression test with your real config before rolling out, and confirm the exception is caught/handled wherever slugs are created in bulk (imports, backfills, seeders).

How to Pitch It (Stakeholders)

For executives (one paragraph): We're evaluating a small, focused Laravel package that handles URL slug generation — the "unique, readable, length-capped" part of publishing content. It's a commodity capability we shouldn't build from scratch, and the reason it's worth a look rather than a shrug is that it comes with an eject option: we can adopt it today and, if we ever want to, move its implementation into our own codebase in a single safe operation. That keeps our exit costs low while removing bespoke slug code from our maintenance burden. The latest patch (v1.0.2) is a quality release: it fixes a case where an over-long slug could be written silently, and it makes the eject operation all-or-nothing so a failed run can't leave an environment half-converted. The one thing to flag is that the fix is a behavior change — some configurations will now get a clear error instead of quietly bad data — so we need a short config audit as part of upgrading.

For engineering leads (summary):

• Correctness fix: unique-slug generation no longer silently exceeds slugsShouldBeNoLongerThan when the limit is shorter than the suffix (e.g., limit 1, suffix -1); it throws InvalidOption. This moves a silent data-integrity bug to a loud, catchable failure — good, but it's a runtime-only failure mode that depends on config plus real content, so add coverage before upgrading and handle the exception in bulk paths (imports, seeders, backfills).
• Safety fix: sluggable:eject is now atomic — files are written to a temp location and only moved if every write succeeds, so a partial failure can't leave a half-ejected application. This makes the command safe to run in scripted/CI contexts and makes "graduate off the package" a credible, documented runbook step rather than a manual, risky chore.
• Versioning caution: shipped as a patch, but the first change is behavioral. Treat the upgrade as a minor-version risk, not a drop-in: audit slugsShouldBeNoLongerThan and suffix configuration across environments, and decide explicitly whether to pin or upgrade.
• Net recommendation: worth adopting where we need configurable, unique, length-capped slugs and value a low-lock-in exit path. Pair it with a database unique constraint for concurrency safety, and keep slug-generation behavior behind our own thin wrapper so we can swap or eject without touching call sites.