Fix: handle boolean-schema validation errors (register validation handler)

[Pravalika-Batchu]

Summary: Add an error handler for boolean-schema validation failures normalized under https://json-schema.org/validation so boolean schemas (e.g. properties: { foo: false }) produce user-friendly error messages.
Fixes: Closes #111
What I changed:
Added validation.js — emits errors for boolean schema failures (skips /additionalProperties to avoid duplicates).
Registered the handler in index.js.
Added a small repro check-boolean.mjs used during verification.
Why: Previously boolean-schema failures were normalized under https://json-schema.org/validation but no error handler was registered, so the library returned an empty errors array for these cases.
Verification:
Tests pass locally: npm test
Notes: This change avoids emitting duplicate messages for additionalProperties

[jdesrosiers]

Thanks for working on this issue. Next time, keep in mind that unless the issue is trivial and obvious, there's should always be discussion before submitting a PR. It helps makes sure everyone understands the issue and what solution we're aiming for so we can minimize any wasted time from going down the wrong path.

The problem with this approach is that now there are two separate ways of handling a false schema. Currently, individual keywords like additionalProperties handle this case. The benefit of that approach is that you can get more customized and context appropriate messaging. The downside is that you end up repeating some of the logic in multiple error handlers.

Your solution takes a different approach where all false schema messaging is handled in one place. The benefit of that approach is that there isn't any duplication, but the downside is that the error message needs to be a little more generic.

I'm fine with either approach, but I like the latter better if we can come up with wording for the message that makes sense in all cases.

What's not ok is a mixture of both approaches. So, either we change additionalProperties so that it doesn't handle false schema messaging itself, or we add false schema handling similar to what additionalProperties does for every applicator keyword. I think changing additionalProperties is going to be the easiest solution.

[jdesrosiers]

This won't always work. Try this schema and you'll see what I mean,

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "properties": {
    "additionalProperties": false
  }
}

Here, "additionalProperties" is being used as a property name, not as a JSON Schema keyword.

[jdesrosiers]

This needs a better name. Try,

Suggested change

	const value = normalizedErrors["https://json-schema.org/validation"][schemaLocation];
	if (value === false) {
	const isValid = normalizedErrors["https://json-schema.org/validation"][schemaLocation];
	if (!isValid) {

[jdesrosiers]

This is not the right error message. This is for the not keyword. I think you're going to need to create a new message for this case.

[Pravalika-Batchu]

Hi Jason — thanks a lot for the review and for the helpful guidance.
Apologies for opening the PR without prior discussion — I’ll make sure to discuss non-trivial changes first going forward.

Summary of changes based on your feedback

Centralized false-schema handling in validation.js. This removes the brittle endsWith heuristic and instead relies on !isValid.

Removed the per-keyword false-schema message from additionalProperties.js to avoid mixing approaches.

Added a dedicated localization helper getBooleanSchemaErrorMessage() in localization.js, along with the boolean-schema-error entry in en-US.ftl.

Updated expectations in keyword-error-message.test.js.

Fixed lint issues and cleaned up code style (prefixed unused args, removed an unused import).

Ran lint and tests locally — everything is passing.

Design tradeoffs & alternatives

Current approach: Using a single centralized handler avoids duplicating logic across applicator keywords and keeps behavior consistent. The error message is intentionally generic:

“The instance is not allowed by the schema.”

Alternative: Handling false schemas on a per-keyword basis would allow more specific, contextual messages (for example, additionalProperties reporting which property is disallowed). The downside is that it would require adding similar logic across all relevant applicators, increasing code size and maintenance overhead.

Since mixing both approaches can lead to inconsistency, I removed the per-keyword handling from additionalProperties and kept everything aligned with the centralized approach.

[jdesrosiers]

Sounds like you have the right idea. However, I see that you pushed a bunch of commits, but nothing has actually changed. Have a look at the "Files changed" tab.