Hashids Bundle Laravel Package

Product Decisions This Supports

• Public identifier strategy (feature): Obfuscating sequential auto-increment IDs in user-facing URLs, API resource paths, share links, invoice/order references, referral codes, and unsubscribe links. This stops trivial enumeration ("/orders/1041, /orders/1042") and stops competitors or scrapers from inferring growth rate from ID gaps.
• Build vs. buy: The underlying algorithm (hashids/hashids) is a small, stable, dependency-free PHP library. The realistic decision is not "adopt this bundle vs. build hashids" — it is "depend on hashids/hashids directly and wire a small service provider/factory" vs. "adopt a wrapper." Given this bundle's signals (1 star, 0 dependents, single maintainer, last release Sept 2022, score 0.005), the defensible roadmap call is use the upstream library, not this bundle.
• Schema decision: Encode/decode on the fly (no migration, but a salt change invalidates every historical link and there's no indexable column) vs. persist a public_id column (migration + unique index, but stable links and queryable). This is a real product trade-off worth an explicit decision record, especially for anything customer-facing or emailed.
• Security posture correction: Hashids is encoding, not encryption. It must never be the access-control mechanism for invoices, documents, or tenant-scoped resources — authorization checks stay mandatory. This kills a common "we'll just hash the ID and call it secure" shortcut before it reaches a design doc.
• Platform fit: Note this is a Symfony bundle, not a Laravel package. For a Laravel codebase this is a non-starter as-is; for a Symfony codebase it's a thin DI convenience over the same library. That framing alone usually resolves the adoption question.
• Roadmap risk input: A single-maintainer, zero-dependent wrapper around a 10-year-old algorithm is a bus-factor-1 dependency. If adopted, plan to vendor or fork it — that's a maintenance-ownership decision, not a technicality.

When to Consider This Package

Consider it when all of the following hold:

• The application is Symfony (this bundle will not serve Laravel).
• You want YAML/DI configuration of salt, minimum length, and alphabet rather than constructing the Hashids object yourself.
• The surface is low-risk and internal-facing, or the IDs are already protected by authorization checks.
• You are willing to pin the version, vendor the code, or fork it, and you accept the single-maintainer maintenance profile.
• You are comfortable that the wrapper adds config ergonomics only — no security, no migration tooling, no observability.

Look elsewhere when:

• You're on Laravel — use a maintained Laravel wrapper (e.g. vinkla/hashids) or bind hashids/hashids in a service provider. Directly cheaper than adapting a Symfony bundle.
• You need security, not obfuscation — signed URLs, encrypted tokens, or opaque random IDs with a database lookup.
• You need sortable, collision-resistant IDs — ULID/UUIDv7 solves the "don't leak counts" problem and stays indexable and time-ordered; Hashids gives you neither.
• You need to defend against a determined attacker — Hashids keyspace is small and salt-guessable; rate limiting and authorization are the actual controls.
• You need a maintained, audited dependency — 1 star and 0 dependents means no ecosystem validation, no upstream backports, no community CVE coverage.

How to Pitch It (Stakeholders)

To executives: This addresses a real but modest problem — our URLs leak sequential IDs, which exposes customer/order volume and invites scraping. The fix is cheap: encoding IDs into short opaque strings. However, the package in front of us is a near-unmaintained single-author Symfony wrapper with essentially zero adoption, so I do not recommend taking it as a dependency; I recommend the underlying library directly, which is small, stable, and free. Effort is low (days, not weeks), and it removes an easy competitive-intelligence leak. It is explicitly not a security control and does not change our authorization requirements.

To engineering: philetaylor/hashids-bundle is a thin Symfony DI wrapper around hashids/hashids — one maintainer, one star, no dependents, last release Sept 2022. Recommendation: depend on hashids/hashids directly and register a small factory/service; if we do adopt the bundle, pin it, vendor it, and treat it as ours to maintain. Either way: (1) salt lives in secrets/env, never in code; (2) define a salt-rotation plan, because rotating breaks every existing encoded link unless we persist a public_id column; (3) add authorization on every endpoint regardless — Hashids is reversible encoding; (4) add round-trip and minimum-length tests; (5) confirm PHP/Symfony version compatibility against the 2022 release before committing.