fix(isFloat): reject unknown locales instead of building a broken pattern

[kory-kaai]

Fixes #2862

Problem

isFloat interpolates the locale separator directly into a new RegExp without checking that the locale exists:

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

When options.locale is not a key of decimal, the lookup yields undefined, which stringifies into the pattern as the literal text undefined. The preceding \\ produces \undefined, and because \u is not followed by four hex digits the escape degrades to a literal u. The compiled separator becomes the eight-character string undefined, so an unrecognised locale silently produces a validator that accepts nonsense and rejects ordinary decimals:

validator.isFloat('3undefined5', { locale: 'no-such' }); // true
validator.isFloat('3.5',         { locale: 'no-such' }); // false
validator.isFloat('3undefined5', { locale: 'de-CH' });   // true

de-CH is a real BCP 47 tag that is simply not among the keys in decimal, so it is a plausible value to reach production.

Fix

Reject an unknown locale before building the pattern:

if (options.locale && !(options.locale in decimal)) {
  throw new Error(`Invalid locale '${options.locale}'`);
}

This matches the existing convention in the library. isAlpha, isAlphanumeric, isDecimal, isIdentityCard, isLicensePlate, isMobilePhone, isPostalCode and isTaxID all throw Invalid locale `${locale}` . isDecimal is the closest precedent because it reads the same decimal table from ./alpha and already throws, so isFloat was the outlier.

The guard is deliberately conditional on options.locale being truthy, so omitting the option keeps using . exactly as before.

Tests

Added a focused should error on invalid locale case for isFloat, following the same shape as the existing cases for isAlpha, isAlphanumeric and isDecimal.

Verified in the order described in AGENTS.md:

• against the unchanged implementation the new test fails with validator.isFloat("123", {"locale":"is-NOT"}) passed but should error
• after the fix it passes
• npm test is green: 324 passing, lint clean, statements/lines/functions at 100%

Notes on scope

• No generated distributions are committed; only src/ and test/ are touched.
• I left README.md unchanged because the sibling validators that throw on an invalid locale do not document that behaviour either, so adding a note only to isFloat would be inconsistent. Happy to add it here, or across the locale-aware validators in a separate PR, if you would prefer it documented.
• I used in to match isDecimal and isAlpha rather than hasOwnProperty. That keeps the change consistent with its siblings; tightening the lookup across all of them felt out of scope for this fix.
• If you would rather not introduce a throw here, falling back to . for an unknown locale is a smaller behavioural change and I can switch it over.

[codecov]

Codecov Report

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

Additional details and impacted files

@@            Coverage Diff            @@
##            master     #2868   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          114       114           
  Lines         2599      2601    +2     
  Branches       658       659    +1     
=========================================
+ Hits          2599      2601    +2     

☔ 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.