[blueDaydreaming725]

Summary

With precision set, locale: true calls toLocaleString on a string and skips numeric formatting. For example, on an en-US system, filesize(1234, { exponent: 0, precision: 6, locale: true }) returns 1234.00 B instead of 1,234 B.

Move the existing non-zero string conversion ahead of both locale branches. Explicit locales retain their current behaviour, while precision strings representing zero and formatting without a locale remain unchanged. Regenerated the tracked distributions with the existing build command.

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

Follow-up to #376; related to #373. This covers the default-locale branch that the explicit-locale fix does not reach.

Testing

• Regression fails before the fix and passes afterwards, covering positive/negative values and padding using the system locale rather than a hardcoded locale.
• npm test: 273 tests pass; line, branch and function coverage are all 100% on Node 24.22.1.
• npm run build: succeeds.
• Independent ESM/CJS/UMD checks with the default locale confirmed as de-DE verify grouping, decimal separators, padding, zero precision and non-locale output. UMD was checked in Node VM, not a browser.

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 API or signature changes; the internal explanation was updated.
• CHANGELOG.md updated (if applicable) — N/A: no version or release change.

Screenshots (if applicable)

N/A — formatting utility change.

[avoidwork]

This is 11.0.29 👍🏻