fix: quadratic error filtering, dropped errors and validation performance

[alexander-akait]

Summary

filterErrors was quadratic in the amount of errors ajv reports, and its lookup used a substring
comparison that silently dropped errors. Fixing both turned into a broader pass over the validation
and error formatting paths, verified against the real sass-loader schema.

Bugs

Quadratic error filtering. For every incoming error filterErrors re-scanned every error kept so
far and rebuilt the accumulated children array. Since allErrors is enabled, ajv reports one error
per offending value, so a large invalid options object was enough to lock up the process: an object
with 40 000 unknown properties took ~8.5s, and 40 000 bad array items took ~90s.

Dropped errors. The lookup was oldError.instancePath.includes(instancePath) - a substring test,
not a path test. Errors were nested under, and for most keywords silently swallowed by, unrelated
errors. Two sibling properties where one name is a prefix of the other were enough to lose one:

validate(
  { type: "object", properties: { foobar: { type: "string" }, foo: { type: "string" } } },
  { foobar: 1, foo: 1 },
);

only reported configuration.foo. The same happened for { a: { b: … }, b: … }, where /a/b was
swallowed by /b.

RangeError for an array of options. The errors of each entry were spread into the result with
push(...errors), which overflows the call stack once an entry reports enough errors - the caller
got RangeError: Maximum call stack size exceeded instead of a ValidationError.

Changes

• Errors are indexed by their instance path in a prefix tree that matches json pointer segments, and
  the children of an absorbed error are adopted rather than copied. Below 24 errors the collected
  errors are scanned directly, which is cheaper than indexing them - that is where the two were
  measured to cross.
• findAllChildren no longer slices the children array on every recursion.
• At most 100 errors of a list are listed in the message, the rest is only counted. A configuration
  with 200 000 invalid values used to produce a 8.9MB message, and a single anyOf error with
  200 000 children a 20MB one. errors still holds every error.
• process.env.SKIP_VALIDATION is read when the module is loaded rather than on every validation.
• Smaller things: the SKIP_VALIDATION regular expressions are hoisted, indent skips the common
  single line case, and the display instance path is built without an intermediate array.

Behaviour changes

Two things worth a close look:

process.env.SKIP_VALIDATION is read once, when schema-utils is loaded. Reading a variable
from process.env goes through an interceptor and costs ~250ns, which was 84% of a successful
validation - the validation itself only takes ~20ns. Writing the variable after schema-utils has
been loaded no longer affects copies that are already loaded; the README now says to set it before
starting the process.

enableValidation()/disableValidation() still take effect immediately. They keep writing
process.env for copies too old to know about it, and share the resolved state through
globalThis[Symbol.for("schema-utils/skipValidation")], so copies of different versions still turn
each other on and off - without the process.env round trip they needed before. That direction is
now covered by a test it never had.

Only the first 100 errors of a list are listed. The rest is counted as and N more errors. No
existing snapshot has more than 100 entries, so nothing in the suite changed.

Results

sass-loader's schema, validated the way loaderContext.getOptions(schema) does, median of 5
processes:

scenario	before	after
valid options	345ns	41ns	6.06x
valid options, all set	399ns	98ns	3.01x
invalid option name	8.8us	8.0us	1.11x
invalid option types	10.7us	9.2us	1.16x
values failing an anyOf	20.6us	17.9us	1.17x
5000 unknown options	60.9ms	1.2ms	45x

For the last one peak RSS goes 145MB -> 91MB and GC time 8064ms -> 194ms, with 24 627 collections
down to 226.

Larger synthetic cases, fresh process each, maxRSS for peak memory:

	cpu	peak RSS	GCs
20 000 errors on one instance path	2.43s -> 0.20s	118MB -> 74MB	391 -> 14
20 000 errors on distinct paths	5.43s -> 0.22s	120MB -> 74MB	395 -> 14
20 000 anyOf failures	22.42s -> 0.39s	185MB -> 108MB	1015 -> 18
one anyOf error, 20 000 children	2.72s -> 0.21s	119MB -> 75MB	394 -> 13

Verification

• 442 tests and 332 snapshots pass, lint and tsc are clean.
• The error messages of the four invalid sass-loader cases are byte identical before and after
  (same SHA-256), including the anyOf case that exercises description and link.
• Differential fuzzing of the old and new filterErrors over 35 302 failing validations found 4
  differences, all of them the dropped error above - the new output never loses a line and gains one
  in 322 of 29 173 cases with prefix sharing property names.
• The scan and the index were compared over 16 400 generated error sets covering 0 to 40 errors and
  every combination of nested, sibling and prefix sharing instance paths: no differences.
• indent was checked against the regular expression it replaces over 27 993 string and prefix
  combinations.
• New tests cover the dropped errors, the RangeError, the listing limit, both filterErrors
  paths, and the state shared between copies. Five of them fail on main.

Things I looked at and did not change

Measured and rejected, so they do not have to be tried again: a non allErrors validator for the
success path (slower on valid data), a WeakMap cache for compiled validators (ajv's own cache hit
is 5.7ns), dropping verbose (4.7ms of a 100ms compile), dropping $data (no runtime effect), and
building the message lazily - it was in this branch for a commit and reverted, because the accessor
costs ~2us per reported error and webpack always reads message.

What is left is outside schema-utils: a successful validation is now ~20ns of ajv plus ~20ns of
our own code, and a failing one is dominated by V8 building the Error - Error.stackTraceLimit = 0
drops new ValidationError from 3945ns to 1115ns.

One thing to flag: SkipValidationState and ErrorPathNode end up exported from
declarations/validate.d.ts, since every typedef in that file does. Happy to restructure if you
would rather not grow the public types.

🤖 Generated with Claude Code

https://claude.ai/code/session_013wqLmVHkAGBsWQgXknEQCK

---

Generated by Claude Code

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ Unknown (46e4533, 4a6fb30, 616d1e8, 654daaf, 7e0a5f4, bd4b9d1)
• ✅ login: alexander-akait / name: alexander-akait (46e4533, 4a6fb30, 616d1e8, 654daaf, 7e0a5f4, bd4b9d1)

One or more co-authors of this pull request were not found. You must specify co-authors in commit message trailer via:

Co-authored-by: name <email>

Supported Co-authored-by: formats include:

1. Anything <id+login@users.noreply.github.com> - it will locate your GitHub user by id part.
2. Anything <login@users.noreply.github.com> - it will locate your GitHub user by login part.
3. Anything <public-email> - it will locate your GitHub user by public-email part. Note that this email must be made public on Github.
4. Anything <other-email> - it will locate your GitHub user by other-email part but only if that email was used before for any other CLA as a main commit author.
5. login <any-valid-email> - it will locate your GitHub user by login part, note that login part must be at least 3 characters long.

Alternatively, if the co-author should not be included, remove the Co-authored-by: line from the commit message.

Please update your commit message(s) by doing git commit --amend and then git push [--force] and then request re-running CLA check via commenting on this pull request:

/easycla

[codecov]

Codecov Report

❌ Patch coverage is 96.71053% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 95.36%. Comparing base (2c0aedf) to head (66cc620).

Files with missing lines	Patch %	Lines
src/validate.js	96.46%	4 Missing ⚠️
src/ValidationError.js	97.43%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #217      +/-   ##
==========================================
- Coverage   95.40%   95.36%   -0.04%     
==========================================
  Files           9        9              
  Lines         848      949     +101     
  Branches      360      387      +27     
==========================================
+ Hits          809      905      +96     
- Misses         35       40       +5     
  Partials        4        4              

Flag	Coverage Δ
integration	95.36% <96.71%> (-0.04%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

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