Eight frontend tests in riexchange.test.ts and utils.test.ts fail on a developer machine whose locale formats numbers with . as the thousands separator: they expect $1,000 and receive $1.000.
Reproduced on a clean origin/main checkout with no local edits, so this is environment-dependent, not a regression.
Why it is worth fixing rather than tolerating
It is a false signal on every local verification. Anyone changing frontend code runs the suite, sees eight red tests, and has to first establish that they did not cause them. This session has had two agents independently reproduce these on clean checkouts to rule themselves out — wasted work each time, and exactly the kind of noise that trains people to skim red output.
The assertions themselves are also weaker than they look: they pin the runner's locale rather than any property of the code, so they pass in CI and fail locally purely by accident of environment.
Suggested fix
Pin the locale at the assertion boundary rather than depending on the host. Either pass an explicit locale to the formatting call under test, or assert against a locale-independent property. Do not fix it by setting a global locale in the jest config alone — that hides the coupling instead of removing it, and the next test to use toLocaleString reintroduces it.
Prefer making the production formatter take an explicit locale where the display code needs one, since a user-visible number format should be a deliberate choice rather than whatever the server or browser happens to default to.
Verification
Run the suite under at least two locales (for example LANG=en_US.UTF-8 and LANG=de_DE.UTF-8) and confirm both pass. A fix verified under one locale has not been verified.
Found while verifying #1727; the eight failures were reproduced on unmodified origin/main before that PR's changes were made.
Eight frontend tests in
riexchange.test.tsandutils.test.tsfail on a developer machine whose locale formats numbers with.as the thousands separator: they expect$1,000and receive$1.000.Reproduced on a clean
origin/maincheckout with no local edits, so this is environment-dependent, not a regression.Why it is worth fixing rather than tolerating
It is a false signal on every local verification. Anyone changing frontend code runs the suite, sees eight red tests, and has to first establish that they did not cause them. This session has had two agents independently reproduce these on clean checkouts to rule themselves out — wasted work each time, and exactly the kind of noise that trains people to skim red output.
The assertions themselves are also weaker than they look: they pin the runner's locale rather than any property of the code, so they pass in CI and fail locally purely by accident of environment.
Suggested fix
Pin the locale at the assertion boundary rather than depending on the host. Either pass an explicit locale to the formatting call under test, or assert against a locale-independent property. Do not fix it by setting a global locale in the jest config alone — that hides the coupling instead of removing it, and the next test to use
toLocaleStringreintroduces it.Prefer making the production formatter take an explicit locale where the display code needs one, since a user-visible number format should be a deliberate choice rather than whatever the server or browser happens to default to.
Verification
Run the suite under at least two locales (for example
LANG=en_US.UTF-8andLANG=de_DE.UTF-8) and confirm both pass. A fix verified under one locale has not been verified.Found while verifying #1727; the eight failures were reproduced on unmodified
origin/mainbefore that PR's changes were made.