v0.3.2
Freeze the clock the relative-time test reads
formatRelativeTime(new Date(Date.now() + 3_600_000), 'auto') measured the
distance a second time, from inside the formatter. The microseconds between
building the date and measuring it made the distance 59.99 minutes, the floor
said 59, and the assertion wanted "in 1 hour". It passed on a fast machine and
failed under the load of a full quality run.
The rounding itself is left alone, and that is the point worth writing down.
Math.floor rounds a negative value away from zero, so ninety minutes reads
"in 1 hour" ahead and "2 hours ago" behind — the same distance answered two
ways depending on its direction. Upstream 3.0.1 does exactly this. The strings
are user-visible, so a migrated application whose timestamps started reading
differently would have no way of knowing why: the asymmetry is pinned by a
test rather than corrected.
Cover the skeleton parser, and make both unit spellings agree
pnpm quality:packages was red here: lines 83.05 against 84, statements 81.17
against 83, branches 69.28 against 73. The gap was one file — the ICU skeleton
parser held 248 of the ~395 uncovered branches, which is the largest thing in
the package and the least exercised.
It turns a compact string into Intl options, and a wrong mapping produces
output that is plausible and wrong. So each expectation is computed from Intl
independently: what is checked is the mapping, not the formatting.
Writing them found a real one. measure-unit/length-meter dropped the
dimension prefix and unit/length-kilometer did not, so the short spelling
reached Intl as an unknown unit and threw. Both now go through the same helper.
Two of my own expectations were wrong and are pinned as the distinctions they
are: ::percent marks the unit without scaling where the classic percent
style multiplies by 100, and dateStyle/full is an Intl option rather than a
skeleton, refused by name instead of read as symbols.
Every threshold passes: statements 84.57, branches 73.52, lines 86.46.
Changes since v0.3.1.