@danxbot/ui 5.1.0 → 5.2.0

package/dist/types/lib/values/phone.d.ts

@@ -0,0 +1,23 @@
+/**
+ * Ten stored digits → `"(555) 123-4567"`. `null` / `undefined` / `""` → `"—"`.
+ *
+ * A non-empty value that is not exactly ten digits after parsing is returned
+ * UNCHANGED — the same "show the corruption, don't hide it behind absence"
+ * rule `formatDate` documents. A stored value should already be `parsePhone`'s
+ * output; if it is not, that is a data problem worth seeing in the row, not
+ * a blank field that looks like nobody ever entered a number.
+ */
+export declare function formatPhone(value: string | null | undefined): string;
+/**
+ * A human-typed phone number → ten stored digits, or `null`.
+ *
+ * Strips everything but digits, so `"(555) 123-4567"`, `"555.123.4567"`,
+ * `"555-123-4567 "` and `"5551234567"` all normalise the same way. A leading
+ * US country code (`"1"`, making 11 digits total) is dropped — `"+1 (555)
+ * 123-4567"` is the same number as `"(555) 123-4567"` and should be stored
+ * identically. Anything that is not exactly 10 digits after that — too few,
+ * too many, or an 11-digit number NOT starting with `1` (a foreign number
+ * mis-typed into a US field, not a US number with an extra digit) — returns
+ * `null` rather than truncating or padding a guess into place.
+ */
+export declare function parsePhone(input: string): string | null;

package/dist/types/pure.d.ts

@@ -24,13 +24,19 @@
  *
  * WHAT BELONGS HERE. Decisions about how a value READS, with no dependencies:
  * precision, units, the point at which a rounded figure stops telling the
- * truth. Deliberately NOT the calendar and time layers — `formatDateRange`,
- * `hoursInDay` and the rest are equally pure and would drag the whole `Intl`
- * time layer behind them, which is a bigger entry answering a question nobody
- * has asked yet. That is a separate decision, to be made when a consumer needs
- * it and not before.
+ * truth. Deliberately NOT the whole calendar layer — `formatDateRange`,
+ * `hoursInDay`, `monthGridDays` and the rest of `lib/time`'s CALENDAR-UI
+ * surface are equally pure but answer a question this entry's consumers do
+ * not have: they are grid-layout and scheduling math, not "turn a stored
+ * value into a string." `lib/values/date.ts` and `datetime.ts` are the
+ * question that WAS asked (a consumer's data grid duplicating this exact
+ * display/parse logic locally, instead of sourcing it from one place) and are
+ * exported below. They reuse `lib/time`'s zone arithmetic internally — that
+ * module has no React in it either, so pulling it in transitively costs real
+ * bytes but not the one thing this entry actually guards against.
  *
  * Everything exported here is ALSO exported from the main entry, so nothing
  * about this is a migration and no existing import has to change.
  */
 export { formatBytes, formatTokens } from "./lib/format";
+export { formatDate, parseDate, formatDateTime, parseDateTime, type FormatDateTimeOptions, type ParseDateTimeOptions, formatCurrency, parseCurrency, formatPhone, parsePhone, formatNumber, parseNumber, type FormatNumberOptions, formatBoolean, parseBoolean, type FormatBooleanOptions, } from "./lib/values";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@danxbot/ui",
-  "version": "5.1.0",
+  "version": "5.2.0",
   "type": "module",
   "description": "Danxbot — a domain-agnostic React design system with motion as a first-class primitive.",
   "license": "MIT",