Slugify Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for slug generation — resolved toward build. The package does not change the calculus; it argues against itself. Its whole value-add is a Symfony2 DI registration plus a Twig filter around cocur/slugify. That is a wrapper around a wrapper. For Laravel, Str::slug() ships in the framework and cocur/slugify is one composer require away, so the "buy" option is already cheap and the "buy this specific thing" option carries cost we don't recover.
• Framework-fit due diligence on incoming dependency requests. This assessment supports a standing rule: when a request names a package, check that the package's target framework matches ours before estimating. Here the description says "Symfony2 slugify bundle," there is no ServiceProvider, no facade, no publishable config, and the bundle lifecycle it depends on (AppKernel registration, DI extensions) does not exist in Laravel. That mismatch is a same-day reject, not an integration ticket.
• SEO & URL strategy roadmap items. Human-readable product and category URLs, canonical redirects, and content migration all need reliable slug generation with transliteration and collision handling. The capability is on the roadmap; this package is not the delivery vehicle. Plan that work against Str::slug() or cocur/slugify and the roadmap dates do not move.
• Uniqueness at write time is the real product requirement. None of the slug options, including this bundle, solve concurrent-insert collisions — that is a database constraint plus application logic. This assessment supports scoping slug uniqueness as an engineering task in its own right rather than assuming a library selection settles it.
• Dependency risk register entry. Two stars and zero dependents means no community validation and no realistic upstream security response. If it ever enters the tree, log it as low-severity but non-zero, and treat its removal as part of any future framework or PHP upgrade.
• Legacy Symfony 2.x service scope. If we maintain an old Symfony app that already depends on this, the supported decision is containment: pin it, do not extend it, and fold replacement into the next platform upgrade rather than opening standalone work.

When to Consider This Package

Adopt only if all of the following hold:

• You are maintaining an existing Symfony 2.x application (EOL since November 2018) that already depends on this bundle, and removal is riskier than keeping it pinned.
• You specifically need its Symfony DI/Twig integration — tagged service, bundle config, |slugify in templates — and have no appetite for instantiating a slugifier directly.
• The application is in maintenance mode with no planned feature work and a contained blast radius.

Look elsewhere in every other case:

• Laravel, any version. There is no bundle registry, no compiler passes, and no loading mechanism. Using it means hand-porting a handful of classes into Laravel's container — at which point essentially nothing of the original package remains. Use Str::slug() for ASCII slugs, cocur/slugify if you need transliteration rules or language hints, and spatie/laravel-sluggable if you want model-level slug lifecycle with uniqueness. All are PHP 8-ready, tested, and actively used.
• Symfony 4+. Use cocur/slugify directly or AsciiSlugger from symfony/string. The bundle layer is redundant.
• Anything requiring active maintenance or a security response path. Assume no patches will ever arrive.
• Multi-language, CJK, or emoji-heavy slugs. A thin wrapper offers no guarantees and no test suite you can audit; verify transliteration coverage explicitly with whichever option you pick.

Two questions worth asking any requester before spending time: what requirement does Str::slug() or spatie/laravel-sluggable fail to meet? and is there a live business driver — for example, a legacy Symfony app where we want shared behavior across both codebases? The second is the only scenario where this bundle has any bearing, and even then the shared artifact should be a standalone library, not a bundle.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. No roadmap item is blocked.

We evaluated happyr/slugify-bundle for slug generation and it fails on framework fit and on maintenance risk. It is a Symfony 2 bundle in a Laravel context — no service provider, no facade, no config publishing — so any use requires us to write custom container wiring around a wrapper we would not otherwise need. The health signals are uniformly poor: 2 stars, 0 dependent projects, and a host framework that has been end-of-life since 2018. Composer will very likely refuse to resolve it against current Laravel and PHP constraints, and there is no community to catch regressions and no realistic path to a security patch.

Engineering. The capability we need already exists: Str::slug() is in the framework, and cocur/slugify is the drop-in if we want richer transliteration rules. Both are PHP 8-ready and actively maintained. Estimated effort to cover our requirements — transliteration, configurable separator, plus uniqueness handled where it belongs, at the database constraint — is under a day with either. That is cheaper than the integration, review, and ongoing ownership work this bundle would demand. The correct pattern, if we want abstraction, is a small Slugifier interface in our own code bound to cocur/slugify; two to four days of investigation with a probable "no" is the realistic frame for adopting the bundle itself.

Product. URL and SEO work proceeds on the same schedule using a first-party approach, with lower long-term maintenance drag and a cleaner dependency story for future framework and PHP upgrades. The one failure mode worth naming: if we did adopt it and later swapped it out, slugs generated before and after could silently diverge, breaking existing URLs and lookups — invisible until a user reports a 404.

If a legacy Symfony 2 service already depends on it. Leave it pinned, add it to the dependency risk register, and fold its removal into the next framework upgrade rather than scheduling standalone work.

Action. Close the request with this rationale and redirect to Str::slug() or spatie/laravel-sluggable. Reserve further spend only for the narrow case where a concrete, documented transliteration requirement cannot be met by either — and even then, extract the character maps rather than take the dependency.