Change Request: Replace and discourage use of JSON schema oneOf

ESLint version

v8.29.0

What problem do you want to solve?

The oneOf property in JSON schemas can cause performance issues. It needs to validate a value against multiple sub schemas in the oneOf array, often all of them. Then it makes sure that exactly one of those matches.

For example, given the following schema:

{
  "oneOf": [
    { "type": "number" },
    { "type": "string" },
    { "type": "object" },
  ]
}

and the following value:

42

• The validator first checks if it’s a number. It is, so now there is one match.
• The validator next checks if it’s a string. It is, so now there is still one match.
• The validator next checks if it’s an object. It is, so now there is still one match.

At this point there is only one match, so the value is valid.

This is a simple example, as are most use cases, but it adds up. With complex / nested schemas this issue can grow exponentially.

What do you think is the correct solution?

Legitimate use cases of oneOf are rare. As far as I recall, I haven’t encountered one yet. Most of the times, the author intended to use anyOf.

With anyOf, the validator can return if a single match is found. Think of it as array.some(fn) instead of array.filter(fn).length === 1

This applies to all ESLint rules in the ecosystem. So I suggest to also discourage usage in the documentation.

Participation

• I am willing to submit a pull request for this change.

Additional comments

I managed to reduce validation time from minutes to milliseconds in an unrelated project by replacing oneOf with anyOf.

[mdjermanovic]

That’s fair, although I do think a user might still choose oneOf if it makes their intent clearer, even if there’s no functional difference.

I consider anyOf as the default choice when multiple schemas are needed, and oneOf as a rarely needed additional constraint that implies that the schemas do overlap and that there’s a specific reason why input must not match more than one, so for me personally the intent is clearer with anyOf when there’s no functional difference between anyOf and oneOf.

I’d also argue that ESLint should provide notes about performance where it seems critical because, from the perspective of consumers (rule authors), ESLint processes schemas and performs validations.

Either way, since there seems to be a consensus around the opinion that in this case the performance impact is negligible, it looks like we can close this issue and the PR https://github.com/eslint/eslint/pull/16692?

[ljharb]

(i think you mean array.filter(fn).length === 1)