Fix: Ensure validation errors are sorted by schema insertion order

[severikupari1]

Summary

This PR addresses #2279 by ensuring that validation errors are returned in the same order as fields are defined in the schema — particularly when multiple nested objects exist at the same level. Previously, validation errors could appear in reverse or unpredictable order due to internal traversal logic.

Problem

When validating schemas with abortEarly: false, Yup collects errors from nested objects but does not guarantee that those errors respect the declaration order within the schema. For example:

const schema = yup.object({
  testObjects: yup.object().shape({
    object: yup.object({ field: yup.string().required() }),
    objectC: yup.object({ field: yup.string().required() }),
    objectB: yup.object({ field: yup.string().required() }),
  }),
})

Produces this incorrect error order:

[
  { "path": "testObjects.objectB.field", "message": "..." },
  { "path": "testObjects.objectC.field", "message": "..." },
  { "path": "testObjects.object.field", "message": "..." }
]

Fix

• This PR implements the following:
• Recursively collects schema field paths (dot notation) in declaration order.
• Adds inline logic in runTests() to dynamically sort nestedErrors using a comparator built from those field paths.
• Introduces a depth limit (default 25) to prevent excessive or infinite recursion.
• Uses a WeakMap to cache paths per schema for performance.

Highlights

• No changes to schema APIs (_sortErrors or options) — logic is entirely contained within runTests().

No breaking changes.

Inline and scoped: only affects the error collection phase when abortEarly: false.

Example After Fix

[
  { "path": "testObjects.object.field", "message": "..." },
  { "path": "testObjects.objectB.field", "message": "..." },
  { "path": "testObjects.objectC.field", "message": "..." }
]

Closes

#2279

Let me know if you'd like to include benchmarks or add a test case into the PR body for reviewers — happy to help tighten it up more!

[jquense]

hey there, thanks for attempting to fix this. The solution here is too complex for a simple sort order convenience. The bug is just in the findIndex function in the existing code. We just need to fix it so it's smarter than looking at specific substrings