2.12.0

This version fixes the typing of toNumber() and toString() by allowing their second parameter to be optional, in line with their behavior and documentation.

See #12 for details.

Thanks @nbran 🙏

2.11.0

This version exports the Numberish type.

See #9 for details.

Thanks @desoss 🙏

2.10.0

This version fixes an issue where projects using Node16 or NodeNext moduleResolution in their TypeScript projects were not able to resolve the types.

See #7 for details.

Thanks @ryangoree!

2.9.0

This version adds toString(), which works like toNumber():

let value = [123456789000000000000000n, 18];

toString(value); // "123456.789"
toString(value, 1); // "123456.8"

Thanks to @DannyDelott for suggesting this! 🙏

2.8.1

API changes:

• format(): now has a signDisplay option, which allows to control how to display the sign for the number. It follows the same rules as the Intl.NumberFormat() signDisplay option.

Bug fixes:

• Fixes an issue with the format() function where the sign was missing from negative numbers with a whole part equal to 0.

Internal changes:

• formatSign(): (internal) returns a number sign.
• toParts(): (internal) the whole part is now always positive. This is to make its behavior consistent: before this change, the sign was only removed when the value of the whole part was 0.

2.7.0

dnum now tolerates numbers that convert into strings using the exponential notation, thanks to from-exponential.

This change goes in the opposite direction than 2.6.1 regarding how numbers with precision loss are handled. The reasoning is that using Number is always prone to precision loss no matter what, and strings or bigints should be preferred to avoid such issues.

dnum.from(10 ** 21)

// 2.6.1 throws:  "The passed number lost its precision: 1e+21. Please use a string, BigInt or Dnum value instead."
// 2.7.0 returns [1000000000000000000000n, 0)

Thanks to @greg-schrammel 🤗

2.6.1

This version adds a specific error message when the passed number gets converted to the scientific notation, making it lose its precision. Thanks @greg-schrammel for spotting this 🙏

dnum.from(10 ** 21)

// Error before 2.6.1: "Incorrect number: 1e+21."
// Error since 2.6.1:  "The passed number lost its precision: 1e+21. Please use a string, BigInt or Dnum value instead."

2.6.0

This version fixes a bug where compare() could return incorrect values.

It also adds the cmp() alias for compare().

2.5.0

With this release, trailingZeros + digits take precedence over the number of decimals, even when digits > decimals.

See #2 (comment) for more details.

Thanks @devnomic 🙏

2.4.1

0 only decimals were incorrectly removed when trailingZeros was set to true, this is now fixed.

Thanks @devnomic for reporting it 🙏