Hashid Bundle Laravel Package

Product Decisions This Supports

• Public identifier strategy for URLs. This is a Symfony bundle that wraps hashids/hashids so integer route params (/order/1042) render as short opaque strings (/order/kJ4x9P). It lets you keep integer primary keys and avoid a schema migration while still shipping non-enumerable links.
• Feature-level: anti-enumeration and metrics hygiene. Sequential IDs leak business volume ("we've had 1,042 orders"), let competitors scrape your catalogue by incrementing a number, and make support tickets guessable. This addresses all three for read-only, non-sensitive resources.
• Build vs. buy. Be clear-eyed: the underlying hashids/hashids library is the product; this bundle is a thin Symfony DI/configuration layer (service definition, YAML config, optional Twig/param converter integration). Buying is rational only because build cost is roughly a day — not because the integration is hard to replicate. If you are not on Symfony, you buy the base library directly and skip this package.
• Roadmap input: one ID decision, made once. Choosing hashids is effectively choosing "integer PKs forever, obfuscate at the edge." If the roadmap includes public APIs, partner integrations, or anything where IDs must be globally unique across shards/regions, evaluate ULIDs or UUIDv7 now — retrofitting later is a routing, serialization, and client-contract change, not a config flip.
• Use cases that fit: public profile pages, invoice/receipt links, marketing and referral URLs, support-ticket links, soft-launch invites, any read-only shareable link where a human retypes or forwards it.
• Use cases that do not: authentication tokens, password-reset links, signed download URLs, anything covered by an authorization decision. Hashids is reversible obfuscation, not encryption — it will not survive a serious security review.

When to Consider This Package

Adopt when all of the following hold:

• You are on Symfony. Note the brief describes this as a Laravel/PHP package — it is not. There is no Laravel service provider here, and 0 dependents plus 13 stars means no community has stress-tested it outside Symfony. On Laravel, depend on hashids/hashids directly and register it in a service provider; that is the same amount of work.
• You already have integer primary keys and a schema migration is expensive, risky, or blocked by other teams.
• The identifiers are internal-only or low-sensitivity — no authorization, no access control, no PII-bearing tokens.
• Your decode path is low-volume and tolerant of a pure-PHP function call on request; this is not a hot-path solution for millions of RPS.
• You accept the maintenance posture: last release 2023-04-27, single-vendor origin (PGS Soft), MIT licensed, no security surface beyond the base library. Pin the version and be prepared to own it. The mitigation is genuinely cheap — swap the bundle for a hand-written service definition in an afternoon.
• You are not required to sort or range-query by the public ID.

Look elsewhere when:

• You need strong opacity or security guarantees. Use encryption (sodium/libsodium), HMAC-signed URLs, or Symfony's UriSigner. Hashids with a leaked salt is trivially decoded.
• You need sortable or time-ordered public IDs. Use UUIDv7 or ULID (symfony/uid), which also solve distributed-generation.
• You want a maintained, actively-versioned dependency for a long-lived public API. sqids is the successor concept to hashids and worth comparing; the original hashids spec is frozen but stable.
• You need multiple identifier formats or per-tenant salts. This bundle's config surface is narrow; you will end up writing your own factory anyway.
• Your team is >1 framework. A framework-agnostic service in your own codebase beats a framework-specific bundle.

How to Pitch It (Stakeholders)

For executives (30 seconds): Our public links currently expose sequential numbers, which tells anyone watching how many customers, orders, or tickets we have, and lets competitors walk our catalogue by changing one digit. This package replaces those numbers with short scrambled strings — same URLs, no database change, roughly one day of engineering. The risk profile is low: the licence is MIT, the algorithm is a stable published standard, and the integration layer is thin enough that we can replace it in-house in a single afternoon if the project goes quiet. It is not a security control — treat it as presentation, not protection.

For engineering (the honest version): This is a Symfony bundle wrapping hashids/hashids, with a low adoption signal (13 stars, 0 known dependents, last release April 2023). Do not mistake it for a maintained framework component. Recommended posture: adopt it as a thin convenience layer with a documented exit ramp — isolate hashid encoding/decoding behind our own PublicIdEncoder interface, register the base library as a service, and let the bundle be an implementation detail. That gives us the config ergonomics today and full ownership whenever we want it, at almost no cost. Explicitly out of scope: authorization, signed URLs, secrets, PII. Add contract tests around decode-failure behaviour (malformed and unknown hashes must 404, not 500) and around the salt being environment-configured and rotated per environment. If the route layer is Laravel rather than Symfony, skip the bundle and wire the base library ourselves.