Laravel Slugidable Laravel Package

Product Decisions This Supports

• URL/permalink strategy. Choosing between title-only slugs (/blog/my-post), ID-only (/blog/12345), and the hybrid this package implements (/blog/my-post-12345). The hybrid is the "safe middle": readable and keyword-bearing for SEO, yet collision-proof and stable when editors retitle content.
• Feature: content authoring UX. Unblocks shipping "edit the title freely" without a redirect-map dependency — the slug suffix is derived from the immutable ID, so retitling doesn't force a URL change. That's a product promise you can put in the CMS authoring spec rather than a caveat.
• Build vs. buy vs. incumbent. The real comparison is not "build this or not" — it's "adopt this, or adopt spatie/laravel-sluggable / cviebrock/eloquent-sluggable, or write a 30-line trait." This package's only differentiation is the title+ID composition; the underlying mechanics are commodity. Scope the decision as "do we specifically need the ID-suffixed pattern, and if so, is 11 stars / single maintainer acceptable?"
• Roadmap input for SEO workstreams. If SEO/clean URLs is a roadmap item, this is a half-day enabler rather than a project. It also constrains later roadmap items: no slug history, no per-locale slugs, no redirect table — if those are on the roadmap, plan for them separately or pick a package that owns that surface.
• Migration/backfill planning. Adopting the convention mid-life means rewriting existing URLs for all rows, which implies redirects and a sitemap refresh. That's the dominant cost of the decision — the package itself is the cheap part.
• Risk register entry. Vendoring risk (bus factor 1, pre-1.0 community validation) versus a low, contained blast radius: it touches slug generation only, sits behind a trait, and is replaceable in an afternoon. Classify as a reversible, low-severity technical dependency rather than an architectural commitment.

When to Consider This Package

Consider it when:

• You're on a modern Laravel version, have a handful of Eloquent models needing public-facing URLs (articles, products, pages, categories), and want this shipped this sprint.
• You specifically want title + ID semantics — i.e., uniqueness must be guaranteed and permalinks must survive retitling with zero redirect infrastructure.
• The team is small, has no dedicated SEO/platform owner, and the URL structure is not a long-term brand contract.
• You have observed or expect slug collisions (duplicate titles — very common in user-generated or bulk-imported content) and want a deterministic resolution without a "check, retry, append -2" loop.
• You're comfortable wrapping it: pin the version, write your own integration tests, and keep the call site behind a trait/interface so you can swap it.

Look elsewhere when:

• The incumbent is safer. spatie/laravel-sluggable has orders of magnitude more adoption, active maintenance, and broader features. Choose this package only if the ID-suffix behavior is a requirement, not a convenience.
• You need more than slug strings — slug history and redirects, localized slugs, transliteration for non-Latin titles, soft-delete-aware uniqueness, or custom slug sources per model. None of that is in scope here.
• URL shape is strategic. Consumer brands, marketplaces, or anything where URL permanence is a public commitment should own this code in-house rather than inherit a single-maintainer dependency's choices.
• Compliance/support requirements exist. No vendor SLA, no security disclosure process, no guaranteed patch cadence.
• The ID leak matters. Appending an auto-increment ID publishes record counts, creation ordering, and a trivially enumerable surface. For private or sensitive resources, use UUID/ULID-based slugs instead.
• Due diligence fails. Verify Laravel version constraints, test coverage, open-issue response, and release cadence before committing — with 11 stars and one maintainer, "last release 2026-06-10" needs to be read as a snapshot, not evidence of a roadmap.

Recommended framing for the decision record: "Adopt behind an internal abstraction, or reimplement the ~40 lines ourselves." Given the surface area, either is defensible; the package's value is mostly in encoding the convention, not in hard engineering.

How to Pitch It (Stakeholders)

For executives (30 seconds): We have a recurring, low-grade content bug: when an editor fixes a title, the public URL either breaks or has to stay ugly, and duplicate titles create collisions. This package removes that class of bug by generating URLs as readable-title-plus-ID — human-friendly for search and sharing, permanently stable, never duplicated. The integration is small and reversible: a trait on the model, no infrastructure, no new service, no vendor lock-in — we can replace it in an afternoon if needed. Cost is effectively zero; the return is fewer broken links, cleaner search indexing, and editors who don't have to think about URLs.

For engineering (the honest version): It's a thin Eloquent trait that composes Str::slug(title) with the primary key. Low risk because it's narrow and swappable; the real risk is dependency hygiene — 11 stars, one maintainer, no evident security process. So: pin the version, vendor or reimplement if the audit is unfriendly, and put our own tests around slug generation. Do not treat it as the answer to slug history, localization, or redirects — those are separate roadmap items. If we don't specifically need the ID suffix, spatie/laravel-sluggable is the lower-variance default and this decision should be framed as "why not Spatie" rather than "why this package."

The one-line ask: Approve a timeboxed spike (half a day) to validate the package against our models and Laravel version; if it holds, adopt behind an internal interface; if not, we implement the convention ourselves and lose roughly a day.