Laravel Nova Hashids Laravel Package

Product Decisions This Supports

• Security remediation, not just a dependency bump. v2 on Nova 4/5 left the card routes effectively unauthenticated (Nova's nova middleware group has not authenticated users since Nova 4), so a guest could enumerate configured connections and encode/decode IDs. v3 adds Nova's Authenticate and Authorize middleware. This is the single strongest input to a "patch now vs. schedule" decision, and it should be triaged as a security advisory rather than a routine version bump.
• Roadmap coupling to Nova 5. v3 requires Nova 5, Laravel 12/13, PHP 8.2+, and vinkla/hashids 13/14, and Composer will not co-install with Nova 3 or 4. Adopting this package version is therefore a forcing function on the platform upgrade path — sequence it inside a Nova 5 / Laravel 12+ migration, not as a standalone task.
• Build vs. buy. The capability is narrow (a Nova card that converts a single model ID to a hashid and back, plus a small HTTP endpoint). It is genuinely buildable in-house in days, but the package is cheap to adopt and now carries tests (PHPUnit, Vitest), a CI workflow, and an extension point (Contracts\Converter) for custom hash algorithms. Default position: buy/adopt; revisit only if the upgrade path collides with a Nova version you cannot leave.
• Support and operations use case. Primary users are internal: support engineers and on-call staff decoding hashids from customer-facing URLs, and admins verifying that a given ID maps to the expected opaque value. Secondary: QA and developers spot-checking encoding during incident triage. There is no end-user product surface here.
• Exposure auditing. Because the v2 route set may have been reachable by unauthenticated users, a PM should decide whether to review access logs for the card endpoint and whether any communication is warranted. v3's fixes (rejecting unconfigured connection names such as main.salt, no HTTP 500 on invalid input, single-ID-only conversion, correct string handling of large IDs, leading-zero/GMP octal fix) also close a set of input-handling defects that could have produced noisy errors and misleading results in support workflows.
• Feature-level gains worth noting, not gating. Auto-conversion of the resource ID on a Nova detail page, Enter-to-convert, copy-to-clipboard, inline error messaging with fields remaining usable, German translations, and a warning when a named connection does not exist. These reduce clicks in the exact workflow the card exists for; treat them as adoption quality-of-life, not as product differentiators.

When to Consider This Package

Consider adoption when:

• You are on, or committed to, Nova 5 with Laravel 12/13 and PHP 8.2+ — there is no middle path, since Composer refuses to install v3 alongside Nova 3 or 4.
• You already expose hashids in user-visible URLs or APIs and want an in-Nova way for staff to decode and verify them without shell access or a bespoke artisan command.
• You need auditable, admin-only tooling rather than a public conversion API. v3's reliance on Nova's Authenticate/Authorize and the viewNova gate is the right shape for this.
• You want a custom hashing scheme — the new Contracts\Converter binding lets you swap the algorithm without forking the package.
• You are currently running v2 on Nova 4 or 5 — upgrade regardless of feature interest, for the authentication fix alone.

Look elsewhere when:

• You are pinned to Nova 3 or 4, or to Laravel below 12 / PHP below 8.2. v3 is unavailable to you; v2 should be treated as unpatched and either removed or the routes locked down at the web-server or route-middleware level.
• You need bulk conversion, batch export, or programmatic encoding inside application code — this is a Nova admin card, not a hashing service. Use vinkla/hashids directly for application logic.
• You need multi-ID or composite-key support. v3 explicitly rejects hashids holding more than one number; the card converts single model IDs only. If your identifiers are composite, this is the wrong tool.
• Your security posture disallows community-maintained packages on an authenticated internal surface with a single maintainer. Mitigations exist (pin the exact version, vendor/fork, review the diff — it is small), but a team with no appetite for that overhead should build the ~one-screen equivalent internally.
• You expect connection switching beyond a fixed select — the card sets a first connection via connection() and warns if it is missing; that is a configuration convenience, not a tenancy model.

How to Pitch It (Stakeholders)

To executives: This is a small, free, internal admin tool for Nova that lets support and on-call staff turn opaque hashids back into real record IDs when debugging customer issues. The headline is not the features — it is that the previous version, when run on current Nova, let unauthenticated visitors list our configured connections and encode or decode IDs. Version 3 closes that hole by putting the card behind Nova's own login and authorization checks. The cost is not a licence; it is engineering time, and that time is largely already spent because v3 only installs on Nova 5 / Laravel 12+, which we need to be on anyway. Recommendation: fold this into the Nova 5 upgrade rather than run it as a separate project, and treat the exposure window on v2 as something to review.

To engineering: v3 is a rebuild for Nova 5 — Vue 3 component built with Laravel Mix 6 and laravel/nova-devtool, Vue 2 components and the Sass file removed. The upgrade is mechanically small but has real gates: hard requirements on Nova 5, Laravel 12/13, PHP 8.2+, and vinkla/hashids 13/14; Composer will not co-install with Nova 3 or 4. The card's internal API changed (selected → connection in requests, new response fields), but the card is the only consumer, so there is no external contract to coordinate. If you added an array_has() shim for issue #2 you can drop it, and you must re-run php artisan route:cache if routes are cached. The important behavioural changes are all defensive: routes now carry Authenticate and Authorize, only configured connection names are accepted, invalid or multi-number hashids return a message instead of a 500, IDs are sent as strings so large values keep every digit, and leading zeros no longer get read as octal by GMP. The package now ships PHPUnit and Vitest suites plus a GitHub Actions workflow, which materially lowers the review burden — read the diff, pin the version, and confirm the viewNova gate matches who you intend to have access.