The decimal check doesn't support scientific notation.

[ivands]

The decimal check should probably support scientific notation.
As it's normal for runtimes to format numbers to scientific notation.

@dosubot what do you think?

[yslpn]

@ivands Thanks for the idea. I was thinking about that too. This looks like a behavioral change.

If decimal() is used before toNumber() or transform(Number), values like 1e309 and 1e-9999 are now accepted, then converted to Infinity or 0 without an issue, because toNumber() only rejects NaN. Previously they were rejected by decimal().

Because of that, I think a separate scientific() action would be safer than expanding decimal(). It keeps existing pipelines backward compatible and makes exponent support explicit.

If #1446 lands, this could look like:

const NumberString = v.pipe(
  v.string(),
  v.oneOf(v.decimal(), v.scientific()),
  v.toNumber(),
  v.finite()
);

With the current syntax, the equivalent would be:

const NumberString = v.union([
  v.pipe(v.string(), v.decimal(), v.toNumber(), v.finite()),
  v.pipe(v.string(), v.scientific(), v.toNumber(), v.finite()),
]);

So my preference would be to keep decimal() for plain decimal strings and add a dedicated scientific() action for exponent notation.

[ivands]

@yslpn My initial thought was to have a single check that checks for both decimal & scientific notation.
But I have no strong feelings about the API, as long as scientific notation is supported.

[fabian-hiller]

@dosu what do you think about this issue? What are our options to support scientific notation?

[dosubot]

The current DECIMAL_REGEX is /^[+-]?(?:\d*\.)?(\d+)$/u [1], and scientific notation (1e3, 1e-3, 1e+3) is explicitly tested as invalid [2]. Here are the main options I see:

Option 1: Extend the existing regex
Update DECIMAL_REGEX to /^[+-]?(?:\d*\.)?(\d+)([eE][+-]?\d+)?$/u. This is the simplest change but would be a breaking change for anyone relying on scientific notation being rejected.

Option 2: Add an optional parameter
Something like decimal({ scientificNotation: true }) to opt in. This preserves backward compatibility but adds complexity and deviates from how other simple string validators (digits, hexadecimal, octal) work — they all take only an optional message [3] [4].

Option 3: Create a separate action
A new action like numeric() or scientificDecimal() that accepts all valid JavaScript number string formats including scientific notation. This follows the library's convention of having focused, single-purpose validators.

Worth noting: Scientific notation parsing already exists in the codebase via the _getDecimalPlaces() helper used in the multipleOf validator for decimal precision [5], so the concept is already handled elsewhere.

Given valibot's modular philosophy, I'd lean toward either Option 1 (if you're okay with the breaking change — arguably scientific notation is a valid decimal) or Option 3 (if you want to keep decimal strictly for "simple" decimal strings and offer a broader validator separately).

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[ivands]

I would agree with @dosubot here.
Option 1 makes the most sense to me, because I was personally surprised it rejected scientific notation.
The reason is that most runtimes actually format numbers to scientific notation if it makes the string smaller.
So the current decimal implementation is probably not what you're looking for.

[dosubot]

Good point about runtimes formatting numbers into scientific notation — that's a practical reason why Option 1 makes sense. If you do String(0.0000001) in JavaScript you get "1e-7", so anyone using decimal() to validate stringified numbers would hit this unexpectedly.

For implementation, the regex change in library/src/regex.ts would be straightforward — going from:

/^[+-]?(?:\d*\.)?(\d+)$/u

to something like:

/^[+-]?(?:\d*\.)?(\d+)([eE][+-]?\d+)?$/u

This would accept 1e3, 1.5e-3, +1E+5, etc. while still rejecting invalid strings. The test cases in decimal.test.ts that currently assert scientific notation as invalid [1] would need to be flipped to valid and expanded with more scientific notation variants.

I'll leave it to @fabian-hiller to decide whether this warrants a major version bump or if it can be treated as a bug fix, given the current behavior is arguably incorrect for its stated purpose.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.