[tests] Pin en-US locale in Meter, Progress, and Slider format tests

[CiscoFran10]

• I have followed (at least) the PR section of the contributing guide.

These tests were failing when the runtime default locale is not en-US, because Intl.NumberFormat(undefined, …) and components without an explicit locale follow the environment. Formatting for USD and grouped numbers then does not match the hard-coded expectations.

FAIL   @base-ui/react (chromium)  src/meter/value/MeterValue.test.tsx > <Meter.Value /> > prop: children > renders a formatted value when a format is provided
Error: expect(element).toHaveTextContent()

Expected element to have text content:
  US$ 30,00
Received:
  US$ 30,00
 ❯ src/meter/value/MeterValue.test.tsx:44:20
     42|
     43|       const value = screen.getByTestId('value');
     44|       expect(value).toHaveTextContent(formatValue(30));
       |                    ^
     45|     });
     

This change pins en-US on Intl.NumberFormat and on the root locale prop in Meter, Progress, and Slider format-related tests so results are consistent in CI and on developer machines.

[pkg-pr-new]

• base-ui-tanstack-start

• vite-css-base-ui-example

  pnpm add https://pkg.pr.new/mui/base-ui/@base-ui/react@4479
  

  pnpm add https://pkg.pr.new/mui/base-ui/@base-ui/utils@4479
  

commit: 799189d

[mui-bot]

Bundle size report

Bundle	Parsed size	Gzip size
@base-ui/react	0B(0.00%)	0B(0.00%)

Details of bundle changes

---

Check out the code infra dashboard for more information about this PR.

[netlify]

✅ Deploy Preview for base-ui ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	799189d
🔍 Latest deploy log	https://app.netlify.com/projects/base-ui/deploys/69c9f6980abf060008595b81
😎 Deploy Preview	https://deploy-preview-4479--base-ui.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[atomiks]

Codex Review (GPT-5.4)

This is a test-only PR aimed at stabilizing locale-sensitive formatting assertions. The deterministic intent makes sense, but the current patch changes the scenario being tested in Meter, Progress, and Slider in a way that diverges from both the documented API contract and the existing NumberField pattern.

1. Bugs / Issues

1. 🟡 Default-locale coverage is replaced with explicit-locale coverage (non-blocking)

Across all six touched tests, the patch now passes locale="en-US" into the component under test instead of only making the expected string deterministic. For example, packages/react/src/meter/root/MeterRoot.test.tsx now effectively tests the explicit-locale branch:

function formatValue(v: number) {
  return new Intl.NumberFormat('en-US', format).format(v);
}

await render(
  <Meter.Root value={30} format={format} locale="en-US">
    <Meter.Value data-testid="value" />
  </Meter.Root>,
);

That matters because Meter.Root, Progress.Root, and Slider.Root all document locale as “Defaults to the user's runtime locale,” and NumberField keeps that default-path behavior covered separately. In packages/react/src/number-field/root/NumberFieldRoot.test.tsx, the prop: format test still uses new Intl.NumberFormat(undefined, ...), and there is also an explicit should use the default locale if no locale is provided test. After this PR, Meter/Progress/Slider no longer exercise the omitted-locale path at all, so a regression in that documented default would now slip through. This is inferred from the diff and the surrounding tests rather than from a fresh runtime repro.

Fix: Preserve an omitted-locale assertion for these components, either by keeping one default-locale format test per component family or by adding dedicated default-locale coverage alongside the new deterministic en-US cases instead of replacing it.

2. Test Quality Assessment

Area	Assessment	Notes
Determinism	Improved	The assertions will be stable if en-US is passed explicitly
Contract coverage	Regressed	The tests no longer verify the documented runtime-locale default
Pattern consistency	Regressed	NumberField keeps default-locale and explicit-locale behavior as separate concerns
Existing explicit-locale coverage	Already handled	Meter/Progress/Slider already have prop: locale tests for de-DE

3. Coverage Gaps / Missing Cases

The missing case after this change is format with no locale prop. That gap is most noticeable in Slider, where the range test previously covered both rendered text and thumb aria-valuetext on the default-locale path. If you want these tests to stay deterministic, I’d still add one small omitted-locale assertion per component family so the documented fallback remains protected.

Merge Confidence Score

Overall merge confidence is 2/5. The patch likely removes the flake, but it does so by switching the tests onto a different API path than the one these components promise by default, and NumberField already shows the stronger pattern to follow. I would address the default-locale coverage gap before merging.