fix(isFloat): fall back to '.' separator for an unknown locale

[yfwmaniish]

Closes #2862.

Bug

isFloat interpolates the locale separator straight into a new RegExp:

const float = new RegExp(`^(?:[-+])?(?:[0-9]+)?(?:\${options.locale ? decimal[options.locale] : '.'}[0-9]*)?...`);

When options.locale is not a key of decimal, decimal[options.locale] is undefined, which stringifies into the pattern as the literal text undefined. The preceding \ yields \undefined, and since \u isn't followed by four hex digits it degrades to a literal u, so the "decimal separator" becomes the 8-character string undefined. There's no error and no fallback:

isFloat('3undefined5', { locale: 'no-such' }); // true  ❌
isFloat('3.5',         { locale: 'no-such' }); // false ❌

Fix

Fall back to . when the locale is unknown:

const decimalSeparator = decimal[options.locale] || '.';

Known locales are unaffected (their separator is always . or ,, both truthy), and the no-locale path already resolved to ..

Tests

Added an unknown-locale block asserting ordinary decimals validate and the undefined-separator strings no longer pass. Verified known-locale behavior (en-US ., de-DE ,) is unchanged.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (a79ff98) to head (f335571).

Additional details and impacted files

@@            Coverage Diff            @@
##            master     #2878   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          114       114           
  Lines         2599      2600    +1     
  Branches       658       657    -1     
=========================================
+ Hits          2599      2600    +1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[nrps9909]

Rechecked ab967e2a64cd3cd63aa863920b6e232a344d1a4e. The ordinary unknown-locale case is fixed, but inherited object keys still bypass the fallback because decimal[options.locale] is truthy for them:

isFloat('3.5', { locale: '__proto__' }); // false
isFloat('3[object Object]5', { locale: '__proto__' }); // true
isFloat('3.5', { locale: 'constructor' }); // false

These also reproduce on the base, so this is incomplete coverage of the intended unknown-locale fallback, not a regression introduced by this PR or a new security claim. Could the lookup check an own property before using the value?

const decimalSeparator = Object.prototype.hasOwnProperty.call(decimal, options.locale)
  ? decimal[options.locale] : '.';

I tested this candidate locally with a regression covering eight inherited names; the new test fails on the current head and passes with the guard. Full candidate npm test passes build, lint and 324 tests; the unchanged head passes 323 tests.

An independent fallback-equivalence matrix covers all 68 supported locales, 10 unknown/inherited names, 11 inputs and six bound-option configurations on source, Node, browser and minified-browser forms. Each form has 5,148 observations: 99 mismatches on base, 75 on this head, zero with the guard. All known-locale outcomes remain identical to base. Unknown-locale expectations use the existing no-locale behavior, so this verifies fallback consistency rather than a complete numeric grammar. Base is a79ff980ab14257e795332989e497bdff3218e87.

No competing PR or changes to your branch. AI-assisted investigation with independently executed checks.

[yfwmaniish]

Great catch — you're right, decimal[options.locale] || '.' still resolves inherited names like __proto__/constructor/toString to truthy Object.prototype values, so they bypassed the fallback and leaked into the pattern (e.g. the separator became [object Object]).

Applied your suggested guard in f335571:

const decimalSeparator = Object.prototype.hasOwnProperty.call(decimal, options.locale)
  ? decimal[options.locale]
  : '.';

Now an inherited name falls back to . like any other unknown locale — isFloat('3.5', { locale: '__proto__' }) is true and isFloat('3[object Object]5', { locale: '__proto__' }) is false. Known-locale behavior is unchanged.

Also extended the tests with an inherited-name matrix (__proto__, constructor, toString, hasOwnProperty, valueOf), asserting ordinary decimals validate and the [object Object] form is rejected. Thanks for the thorough differential check.

[nrps9909]

Thanks for applying the own-property guard and adding the inherited-name regressions. Revalidated exact head f3355718020ef3addf989727617baa65105f03e2.

• Full npm test: 323 passing; generated builds and ESLint pass on Node 24.15.0.
• Re-ran the independent 5,148-observation fallback-equivalence matrix on each of source, Node, browser, and minified browser forms: the previously reviewed head has 75 mismatches per form; this head has zero. All 68 declared locale keys preserve baseline behavior. The unknown-locale controls include all eight inherited names from my earlier probe, including isPrototypeOf, propertyIsEnumerable, and toLocaleString.
• All 13 currently exposed upstream checks pass.

This resolves the inherited-property fallback gap reported in my previous review. The matrix checks locale fallback equivalence and selected numeric bounds; it is not an exhaustive float-grammar conformance claim.