Hashids Bundle Laravel Package

Product Decisions This Supports

• User-facing ID obfuscation — deciding whether order numbers, invoice IDs, or user IDs should be sequential (/orders/1042) or opaque (/orders/x7Kp2m). This package is a thin Symfony integration of the hashids/hashids library, so it informs the "do we expose raw auto-increment IDs?" decision.
• Enumeration & scraping risk mitigation — supports the argument that predictable IDs make it trivial to walk your dataset. Relevant for public URLs, sharing links, and any resource where the ID leaks business volume.
• Build vs. buy — this is a ~100-line wrapper around an existing library. The real decision is whether to (a) adopt the underlying hashids/hashids library directly, (b) migrate to sqids/sqids (the maintained successor), or (c) write a 30-line encoder in-house. This bundle adds almost no product value over the base library.
• Framework fit decision — despite being framed as a "Laravel/PHP package," this is a Symfony bundle (netbull/hashids-bundle). It is not Laravel-native (no service provider, no config publishing convention). For a Laravel codebase, treating it as a candidate would be a category error.
• Legacy/roadmap input — worth flagging that Hashids itself is in a "maintenance-only, use Sqids instead" posture. Any roadmap item that depends on Hashids encoding is a mild technical-debt decision, not a greenfield one.

When to Consider This Package

Only if all of the following are true:

• You are on Symfony (this is a bundle, not a Laravel package — the brief's framing is inaccurate).
• You have already accepted AGPL-3.0 as compatible with your distribution model. This is the gating issue: AGPL is copyleft and network-triggering. For a SaaS or commercial product, legal review is mandatory before adoption; many orgs have a blanket AGPL ban.
• You want the Symfony DI/config ergonomics of a bundle (auto-registered service, YAML config) rather than instantiating the library yourself — and that ergonomic benefit outweighs the risk profile below.

Look elsewhere — strongly — if any of these apply:

• You are on Laravel. Use hashids/hashids directly or, better, sqids/sqids behind a small service class. There is no reason to pull in a Symfony bundle.
• You need security. Hashids is obfuscation, not encryption — it is reversible and has known weaknesses. Do not treat it as an access-control or tamper-proofing mechanism. Use signed URLs (URL::signedRoute in Laravel) or UUIDv7/ULID for that.
• Provenance matters. 0 stars, 0 dependents, a single unvalidated release, and a low quality score (≈1.84) mean no community validation, no ecosystem pressure to keep it patched, and no failure stories to learn from. For anything on a critical path, prefer the underlying library with millions of downloads over a wrapper with zero.
• You want longevity. Since the base library is now effectively superseded by Sqids, adopting a thin 2025 wrapper around a deprecated-in-spirit library is a poor 3-year bet.

How to Pitch It (Stakeholders)

For executives (one line): "A small utility for making sequential IDs in URLs harder to guess — but the specific package is an unproven Symfony-only wrapper under a restrictive AGPL license, so I recommend we implement this in-house using a maintained library rather than adopt it."

For engineering:

• The capability (hiding sequential IDs) is worth having; the package is not the right vehicle.
• Recommend: implement a small IdObfuscator service backed by Sqids (maintained successor to Hashids) or, if signed/tamper-proof IDs are needed, use framework-native signed URLs. This removes the AGPL exposure, the Symfony/Laravel mismatch, and the single-maintainer risk in one decision.
• If the team insists on Hashids semantics, depend on hashids/hashids directly (well-known, widely used) and skip the wrapper entirely — it's a configuration convenience at best.
• Flag the underlying weakness clearly: Hashids is not security. Any requirement phrased as "so users can't access other people's records" must be solved with authorization, not obfuscated IDs.

Net recommendation: Pass on adopting netbull/hashids-bundle. Reuse the decision it represents (obfuscate public IDs) but source it from a maintained library under a permissive license, integrated natively for your framework.