[ybai08]

Summary

The scientific-notation expansion added in #344 has two gaps:

1. It calls toLocaleString("en-US", { useGrouping: false }), and Intl's default maximumFractionDigits is 3. A rounded value small enough for toString() to give exponent form (below 1e-6) is therefore truncated to "0":
   • filesize(1, { exponent: 3, round: 10 }) returns "0 GB". The rounded value is 1e-9, so the expected result is "0.000000001 GB".
   • filesize(5, { exponent: 3, round: 9 }) returns "0 GB".
   • filesize(1, { exponent: 3, round: 10, pad: true }) returns "0.0000000000 GB".
2. It runs after the custom separator has been applied, when the value is already a string, so the check never matches on that path:
   • filesize(1, { exponent: 3, round: 10, separator: "," }) returns "1e-9 GB".
   • filesize(1e22, { exponent: 0, separator: "," }) returns "1e+22 B". Without a separator it returns "10000000000000000000000 B".
   • filesize(Number.MAX_VALUE, { separator: "," }) returns "1,7976931348623158e+284 YB".

This PR moves the expansion into the non-locale branch, after the pad-rounding step and before the separator replacement, and passes maximumFractionDigits: 20. 20 is the largest value every Intl implementation accepts. The locale branches are unchanged: they already return strings, so the old check never ran on them. The precision path is also unchanged, because its value is a toPrecision() string.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature / enhancement
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Build / dependency / tooling change
• Test additions or updates
• Other

Related Issues

refs #343 (item 8, "Strip scientific notation in non-precision path"). No open issue or PR covers these two cases.

Testing

Two tests were added under "Edge case hardening (issue #343) › Sign handling", next to the existing Number.MAX_VALUE test:

• should not truncate small values when expanding scientific notation
• should not leak scientific notation with a custom separator

Before the fix, both fail on master (actual: '0 GB' and actual: '1e-9 GB'). With the fix, both pass:

node --test --test-name-pattern='truncate small values|leak scientific notation with a custom' tests/unit/filesize.test.js

npm test (oxlint + oxfmt check + node:test with coverage) passes: 271 tests, with 100% line, branch and function coverage for src/. npm run build succeeds, and the tracked dist/ files were regenerated. All of this was run on Node 26.10 (macOS).

A broader before/after probe of about 55 option combinations (locale, pad, separator, precision, bits, BigInt, fullform) changed only the 1e22 + separator case.

Known limit: a value that needs more than 20 fraction digits, which only happens with round > 20, still rounds to zero.

Checklist

• npm test passes
• npm run build succeeds
• 100% test coverage maintained
• No hardcoded secrets or credentials introduced
• Zero external dependencies added
• ES Modules only (no CommonJS in src/)
• JSDoc comments added/updated (N/A: no function signatures changed; an inline comment was updated)
• CHANGELOG.md updated (if applicable): N/A, the changelog is generated at release by auto-changelog

Screenshots (if applicable)

N/A