{"version":3,"sources":["../src/validation.ts"],"names":["isValidPhoneNumber"],"mappings":";;;;;AAkCO,IAAM,YAAA,GAAe,CAAC,KAAA,KAC3B,4BAAA,CAA6B,KAAK,KAAK;AAyBlC,IAAM,YAAA,GAAe,CAC1B,cAAA,EACA,WAAA,KACY;AACZ,EAAA,IAAI,CAAC,cAAA,IAAkB,CAAC,WAAA,EAAa,OAAO,KAAA;AAC5C,EAAA,MAAM,KAAK,WAAA,CAAY,UAAA,CAAW,GAAG,CAAA,GAAI,WAAA,GAAc,IAAI,WAAW,CAAA,CAAA;AACtE,EAAA,OAAOA,sBAAA,CAAmB,CAAA,EAAG,EAAE,CAAA,EAAG,cAAc,CAAA,CAAE,CAAA;AACpD","file":"validation.cjs","sourcesContent":["/**\n * @hanzo/iam/validation — canonical identity-attribute validators.\n *\n * One source of truth for \"is this a valid phone number / email / etc.\"\n * across every Hanzo product (web, mobile, server). The Go IAM server\n * normalizes phones to E.164 on store and looks them up by E.164 on\n * read; this module is the JS/TS counterpart so frontends produce the\n * exact form the server expects.\n *\n * Importing from @hanzo/iam/validation has zero runtime cost beyond\n * libphonenumber-js — no IAM client construction, no JWT verification,\n * no React. Safe for any environment (browser, Node, React Native).\n *\n * @example\n * ```ts\n * import { isValidPhone, isValidEmail } from \"@hanzo/iam/validation\"\n *\n * isValidPhone(\"6178888888\", \"+1\")    // true  — boston US number\n * isValidPhone(\"6178888888\", \"\")      // false — no country code\n * isValidPhone(\"5550110001\", \"+1\")    // false — US 555-01XX reserved\n * isValidEmail(\"user@example.com\")    // true\n * ```\n */\n\nimport { isValidPhoneNumber } from \"libphonenumber-js/min\"\n\n/**\n * Email format check — RFC 5322 in spirit, single-line regex in practice.\n *\n * The server validates against a more thorough RFC parser; this is a\n * cheap client-side gate to flip the Send Code button. False positives\n * (passes here, server rejects) fall back to a clear server error;\n * false negatives don't exist for any well-formed address.\n */\nexport const isValidEmail = (email: string): boolean => (\n  /^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$/.test(email)\n)\n\n/**\n * Strict E.164 phone validation.\n *\n * `nationalDigits` is the digits the user typed — no `+`, no country\n * code prefix. `countryCode` is the dialing prefix selected from the\n * country dropdown — `\"+1\"` for US/CA, `\"+44\"` for UK, etc. Either\n * `\"1\"` (no leading `+`) or `\"+1\"` (with) is accepted.\n *\n * Returns true only when libphonenumber-js's national-numbering-plan\n * tables say the resulting E.164 is a real, dial-able number in that\n * country. Reserved/fictional ranges (US 555-01XX, GB 7700-9XXXXX,\n * country-test pools) fail here even though they pass a naive length\n * check.\n *\n * Why strict matters: a permissive length-only check accepts inputs\n * like `6178888888` with no `+1` selected. Frontends then store the\n * raw national digits, the IAM server records them without a country\n * prefix, and a later login attempt (which always sends E.164\n * `+16178888888`) fails to match the stored row. The user appears to\n * be a different account and their data goes invisible. One canonical\n * validator on every input prevents the divergence.\n */\nexport const isValidPhone = (\n  nationalDigits: string,\n  countryCode: string,\n): boolean => {\n  if (!nationalDigits || !countryCode) return false\n  const cc = countryCode.startsWith(\"+\") ? countryCode : `+${countryCode}`\n  return isValidPhoneNumber(`${cc}${nationalDigits}`)\n}\n"]}