// the find
shuding/nstr
number → string, but looks good
nstr is a one-function TypeScript package that takes a number and returns a string with floating-point noise removed, so 0.1 + 0.2 prints as 0.3 and 19.9 * 100 prints as 1990 instead of 1989.9999999999998. It is aimed at front-end code that displays computed values, such as CSS transforms and prices. Under the hood it is a digit-pattern heuristic applied to toFixed(10) output, not a numeric method.
The README examples hit the failure modes people actually see in UI code: 0.14499999582767487 should read 0.145, and a tiny negative like -0.0000001 should not render as -1e-7. The API is two options with one-sentence meanings, threshold (how many consecutive 0s or 9s trigger cleanup) and maxDecimals (a cap on decimal places), so a call site can tune how aggressive it is without reading the source. It returns a string, which is what a template literal or a style attribute needs, so there is no second formatting step afterward.
It matches digit patterns rather than bounding error, so a real value with a run of four zeros or nines after the decimal point looks like float noise to it. The README's own threshold: 2 example shows the cost: 0.1239991 comes out as 0.123, which discards real digits. Tuning threshold is the only lever, and the docs give no guidance on picking it for a given value range. The output is also lossy by design and does not say so. -0.0000001 becomes '0', and nothing in the return value tells the caller that digits were dropped. That is fine for a transform and wrong for money or measurement data, and the README does not warn about it. Upkeep looks thin: the last push was 2025-10-21, about a year before today, and the visible tree has a single test.js and no CI config. The tree is truncated, so this may be incomplete, but I would read the tests before depending on it.