Saudi Id Number Laravel Package

Product Decisions This Supports

• KSA market-entry readiness (back-office slice). If the roadmap includes Saudi customers or Saudi-based operations staff, this package informs one narrow decision: how we capture and visually validate national ID numbers inside Laravel Nova admin screens. It is a data-entry UX detail, not a market-entry enabler.
• Build vs. buy for commodity admin fields. This is a useful reference case for a policy question: when do we pull a third-party Nova field versus writing 30 lines of Vue plus a regex/Luhn check? At 1 star, zero dependents, and no release since August 2018, it sits firmly on the "build" side of that ledger — but the category (small, well-scoped field types) is worth standardizing on internally.
• Vendor and dependency risk posture. Adopting this would be our first dependency on an unmaintained Nova field. That triggers a broader decision about whether we allow single-maintainer packages in admin tooling at all, and what the fallback (fork, vendor, or reimplement) looks like.
• Operational data quality for KYC-adjacent workflows. If support, finance, or compliance staff look up Saudi customers in Nova, frontend validation reduces mistyped IDs at intake. That is a measurable reduction in support rework — but only if server-side validation exists, which this package explicitly does not provide.
• Explicitly not supported: customer-facing decisions. Nova is a paid internal admin panel. This package cannot be used for storefront signup, checkout, mobile onboarding, or any public form. Any roadmap item about "validate Saudi IDs at registration" must be resolved elsewhere; do not let this package's existence imply the capability.
• Localization roadmap signal. The existence of this field hints at a broader KSA localization surface (Iqama/resident ID distinction, Arabic-first admin labels, Hijri date handling, national address formats). This package covers one sliver; treat it as a prompt to scope the rest rather than as a solution.

When to Consider This Package

Consider it only when all of the following hold:

• You are running a Nova version contemporary with the 2018 release (Nova 1.x/2.x era). Nova's field API has drifted substantially since; assume incompatibility with Nova 3/4/5 until proven otherwise in a spike.
• The use case is strictly internal admin data entry — staff typing a Saudi national ID into a Nova resource form.
• Server-side validation already exists or is on the same sprint's backlog. The package's own description states it validates on the frontend only and will not prevent form submission; it is cosmetic feedback, not a control.
• The work is a prototype, spike, or short-lived internal tool where a 2018 dependency is acceptable and disposal is cheap.
• Your team has no Vue/Nova field experience and the one-to-two days to build a custom field is genuinely scarce.

Look elsewhere when:

• You are on Nova 3, 4, or 5 — treat this as non-viable and budget for a rewrite or an in-house field.
• The requirement is customer-facing, regulatory, or KYC-grade. National ID validation for compliance needs server-side enforcement, checksum logic, audit trails, and likely a distinction between citizen IDs (leading 1) and resident/Iqama IDs (leading 2). None of that is here.
• You need maintainership, security response, or any support expectation. Last release 2018-08-25; one star; zero dependents; no community to inherit maintenance from.
• You need adjacent capability: multi-country GCC ID formats, Arabic-language error messages, Hijri dates, or integration with Saudi national address data.
• You need a single, consistent validation rule. A maintained server-side Laravel validation rule paired with a minimal in-house Nova field gives you one source of truth instead of a frontend-only check that silently diverges from the backend.

Practical alternatives, in preference order:

1. Write an in-house Nova field (a Vue component plus a regex and Luhn checksum) backed by a server-side Laravel validation rule. This is a small, well-understood piece of work and eliminates the dependency entirely.
2. Adopt a maintained Saudi national ID validation rule on the server, then surface its error message in Nova through a lightweight custom field.
3. Fork this repository, pin it internally, and accept ownership. Only justified if the 2018 code is somehow already load-bearing, which it is not.

How to Pitch It (Stakeholders)

For executives (one paragraph). We evaluated a small open-source add-on that adds a validation hint for Saudi national ID numbers in our internal Laravel admin panel. It is free, MIT-licensed, and does one thing: it shows staff a visual warning if an ID looks wrong. It does not block submission and does not validate anything on the server, so it is a convenience, not a compliance control. The package was last updated in 2018, has one star, and no projects depend on it — meaning we would be its only real user and its de facto maintainer. My recommendation is do not adopt it; the same behavior is a one-to-two-day in-house build that we would own outright. This is not a blocker for any KSA roadmap item, and it should not be presented as evidence that we have Saudi ID validation "handled" for customer-facing flows.

For engineering leads. The value proposition is thin: a Nova field with client-side formatting and validation feedback. The costs are concrete: an unpinned 2018 dependency, likely incompatibility with current Nova, no upstream security response, and a validation rule that lives only in the browser. The correct pattern is server-authoritative validation with the frontend purely as UX. If we want the UX, build a small custom field wrapping a shared validation rule — we get one source of truth, testability, and a clear owner. If someone wants to trial this package anyway, do it in a throwaway branch against our actual Nova version first, and pair it with a server-side rule before anything reaches production.

Recommendation summary.

• Decision: Decline adoption; build in-house or use a maintained server-side rule.
• Effort: 1–2 engineer-days for the custom Nova field plus server rule.
• Risk avoided: single-maintainer dependency, stale framework API, false sense of validation coverage.
• Revisit if: the repository shows renewed maintenance and we have a genuinely disposable internal tool where the one-to-two days is not available.
• Do not communicate this package's existence as progress on KSA customer onboarding, KYC, or regulatory readiness — those require server-side enforcement and are out of scope here.