Safe Number Input

Across seven ordinary inputs and four widely-used libraries -- numeral.js, numbro, accounting.js, and the naive strip-non-digits sanitizer -- 22 of 28 results are wrong. Reproduced directly, not quoted: numeral returns 25 for a twenty-five-million input, accounting returns 25, numbro returns undefined. numeral is the instructive one: it handles k and not M, so it is right often enough to be trusted and wrong on the largest values. That is worse than always wrong, which gets caught by the first test.

None of these throw. The form saves, the toast says Saved, and the page renders a completely plausible number.

THREE RULES. Ambiguity refuses: 1.234 is 1,234 in Berlin and 1.234 in Boston, and a library that picks silently is wrong for half the world. Unknown suffixes refuse: ignoring a suffix you do not recognise IS the million-fold error. Empty is not zero: an empty string means not entered, and coercing it to 0 fabricates a data point.

Also: accounting parentheses, exact minor units where Math.round of 1.005 times 100 gives the wrong answer, currency detection, and type separation so a percentage can never be assigned to a money field.

VERIFIED: 26 tests, 6/6 mutations caught. Two of those tests exist because mutation testing found gaps in my own suite, and one because the parser was right where my test was wrong.

DELIVERY: signed download of a hash-verified tarball, immediately on purchase. Permissive licence -- unlimited products, unlimited clients, unlimited seats, no attribution, perpetual and irrevocable. One restriction: do not republish the source as source.

Interface

What you call, and what comes back. Types and signatures only — the implementation ships with the source.

  export function parseNumber(input: unknown, opts: ParseOptions = {}): Parsed;
  export function parsePercent(input: unknown):;
  export function parseMultiple(input: unknown):;

  export type Parsed = | { ok: true;
  export type SeparatorStyle = "dot_decimal" | "comma_decimal";