Combine const/enum with type error handling

[jdesrosiers]

If there's a const or enum, a type error message is unhelpful.

{
  "type": "string"
  "const": "foo"
}

42

Error messages:

• Expected a string
• Expected exactly "foo"

The type message isn't helpful because the const message is more specific. To deal with this problem, we can combine the type handler with the const/enum handler and display only the most specific message.

[Sam-61s]

Hi @jdesrosiers,

I’m thinking of collecting type, const, and enum results first and then emitting only the most specific error per schema location using a simple priority rule:

const > enum > type

If const or enum fails, we won’t show the type error because it doesn’t add useful information. This will reduce extra error messages and keep the output clear and simple.

If this direction looks good, could you please assign this to me ??

[jdesrosiers]

@Sam-61s That approach ignores the work that's already been done for the const/enum handling. Read up on #132 and #155 and the current code, then try again.

[Sam-61s]

Hey @jdesrosiers,

I've studied #132 and understand the approach now.
Solution: Modify the type handler to check if const/enum constraints exist in normalizedErrors If present, skip the type error since const/enum is more specific.

This follows PR #155's pattern of collecting all constraints and respects the handler order (constEnum runs before type). The type handler just needs an early return when it detects const/enum keywords present.

Does this approach make sense?

[jdesrosiers]

Solution: Modify the type handler to check if const/enum constraints exist in normalizedErrors If present, skip the type error since const/enum is more specific.

I was thinking we we're going to have to combine the type and const/enum handlers into a single handler, but that might be better. However, we do still need to take type into account in the const/enum handler. Here's another case I just thought of that illustrates why.

{
  "allOf": [
    { "type": "string" },
    { "enum": ["foo", 42] }
  ]
}

The response should be that the expected value is "foo". The const/enum handler should recognize that 42 can never pass because it's not a string and filter out that option. Keep in mind that in this case, enum can pass but still need to produce a message. Consider the instance 42. enum would pass, but the const/enum handler would still need to say that the expected value is "foo".

Go ahead and start work.