Support errorMessage

[Ahmedmhmud]

Summary of changes

Added support for the errorMessage keyword in diagnostic messages.

• When a subschema’s keyword fails validation and that subschema defines errorMessage, the diagnostic now shows the custom message instead of the default one.
• Resolution works by taking the failing keyword’s schemaLocation, stepping back to its parent, and reading errorMessage directly via getSchema() + Browser.value().
• Confirmed working through $ref, nested anyOf/oneOf alternatives, and cases with multiple schemaLocations per error.
• formatError() (and the functions that build on it) were changed from synchronous to async, since the lookup requires getSchema(). Existing formatError unit tests were updated to await/.resolves accordingly but the behavior of course is unchanged.

Unlike defaultSnippets/markdownDescription, errorMessage is not registered in the vscode.ts, the lookup reads the raw schema value directly rather than going through the annotation/keyword-recognition system, so registration isn’t actually necessary for this feature. I chose not to add it, but wanted to flag in case we’d prefer it registered anyway for consistency with the other VS Code keywords.

Closes #134

[jdesrosiers]

Using getSchema won't always work for a variety of reasons. Have another try at this. Below is the direction I have in mind.

1. Match VS Code's semantics

VS Code only uses errorMessage for type, enum, and const errors. patternErrorMessage (with a fallback to errorMessage) is used only for pattern and format errors.

Right now errorMessage replaces every message coming from a subschema, so it can hide unrelated failures:

{
  "type": "string",
  "minLength": 5,
  "errorMessage": "Must be text"
}

With "abc", the user should see "Expected a string with at least 5 characters", not "Must be text" because minLength was what failed, not type.

2. Register errorMessage and patternErrorMessage as vscode keywords

One of the reasons reading Browser.value(parentSchema).errorMessage isn't good enough is because it goes around the vocabulary system. We never rely on actual keyword names. It always has to be based on the keyword URI.

Each of these keywords also needs defineKeyword(id, { annotation: true }) from @hyperjump/json-schema-errors. Without it, @hyperjump/json-schema-errors throws an unsupported keyword error. Please add this for the existing two keywords as well.

3. Get the message from the evaluation, not by re-fetching schemas

The current lookup has a few problems:

• It calls getSchema again for every error and every schema location, on every validation. The schemas were already compiled.
• It finds the parent schema by cutting the location at the last /. That doesn't work for boolean schemas or error-handler locations, and the empty catch hides those cases.
• It makes formatError and everything that calls it async, just to look up a string.

The validator already has all of this while it runs. Use an EvaluationPlugin instead. I think a separate plugin from LspEvaluationPlugin makes sense this time. Only schema-validation diagnostics uses this, so the plugin belongs in src/features/diagnostics/. That keeps the feature removable as one unit.

4. Values

• Outside the VS Code dialect these are unknown keywords, so they can hold anything. ajv-errors schemas commonly use an object form, "errorMessage": { "type": "..." }, which would currently show up as [object Object]. Ignore values that are not string values.

[Ahmedmhmud]

Totally makes sense
Sorry for the misunderstanding, I'll take another look on it.
Thanks!