Sqids Bundle Laravel Package

Product Decisions This Supports

• Opaque-but-short public identifiers. Lets you ship human-friendly, non-sequential IDs in URLs, share links, invoice/reference numbers, and support conversations without exposing auto-increment primary keys. This is obfuscation, not security — it must not be the control that protects access to a record.
• Build vs. buy for ID encoding. The underlying algorithm (sqids/sqids-php) is small and permissively licensed; this bundle is DI/configuration glue for Symfony. The honest decision is: buy the glue if you're already on Symfony and want a configured service with per-entity alphabet/min-length; build (≈20–30 lines binding the library in a service provider) if you're on Laravel, where this bundle is not directly usable.
• Use cases worth queuing: shorter public slugs, support-friendly order/reference codes, encoding multiple integers into one token (e.g. entity ID + tenant/epoch), and replacing an ad-hoc base62/hashids helper scattered across the codebase.
• Roadmap signal, not a roadmap driver. v0.10.0 is a single-line compatibility change (a return type on loadInternal). It tells you the package tracks Symfony majors; it does not indicate an active feature roadmap. Plan for this dependency as small and replaceable, not as a platform component.
• Explicit anti-decision: do not adopt it for capability URLs, password-reset tokens, API keys, or anything requiring non-reversibility. Sqids is reversible by design; those need random tokens with hashed storage, or UUIDv7/ULIDs.

When to Consider This Package

Adopt when:

• You're on Symfony (6.4/7.x today, 8.x now unblocked by v0.10.0) and want Sqids available as a configured, injectable service rather than hand-wiring the library.
• You need per-entity configuration — distinct alphabets and minimum lengths for different ID types — managed centrally in bundle config.
• The requirement is genuinely cosmetic/UX (shorter, non-sequential IDs) and the encoded value is not the sole authorization check.
• You're comfortable pinning a ^0.10 dependency and accepting pre-1.0 API churn.

Look elsewhere when:

• You're on Laravel. This is a Symfony bundle. Use sqids/sqids-php directly behind a thin service provider or value-object wrapper; you gain nothing from the bundle and lose a dependency.
• You need irreversible or unguessable tokens. Use random tokens stored hashed, or UUIDv7/ULID. Sqids is decode-able by anyone with the alphabet.
• You need API stability or a support SLA. 0.x, single maintainer, low release cadence. Acceptable only because the blast radius is tiny and swapping it out is a day's work at most.
• You need collisions guaranteed impossible across a large keyspace with hard length constraints — validate the Sqids blocklist/min-length behavior against your expected volume before committing.

Release-specific note for v0.10.0: the change adds a return type to loadInternal. This is backward-compatible for consumers (no config or container changes), but is technically breaking if you subclass or extend the bundle's DI extension. It is the gate that lets Symfony 8 upgrades proceed; without it you're pinned to Symfony 7.x.

How to Pitch It (Stakeholders)

To executives: This is a tiny, free, MIT-licensed glue package that makes customer-facing IDs shorter and less revealing than raw database counters. Cost is effectively zero and it's easily replaced, so risk is low. The one thing to be clear about: it hides patterns, not data — it is not a security or access-control measure, and it should never be the thing standing between a user and someone else's record. The new release is a one-line Symfony 8 compatibility fix, not a capability change.

To engineering: v0.10.0 adds a return type to loadInternal for Symfony 8 compatibility; upstream Sqids behavior is unchanged, no config migration, no container changes. Only relevant if you extend the bundle's extension class — then it's a signature change. The broader caveat: this is a 0.x package with one maintainer and a very small surface area. Treat it as an implementation detail behind your own interface (e.g. an IdEncoder contract) so a future swap to ULIDs or a bespoke encoder stays a one-file change rather than a refactor. If you're a Laravel shop, skip the bundle and bind sqids/sqids-php yourself.