locations.json schema fails common validator Ajv on multiple counts

[jhobz]

The schema definitions should be compliant with common validators so that plugins or other programs looking to share the same schema can also run their own validation. I'm creating a tool to assist in pack building and I want to be sure that my output is verified against the schema, but I currently can't run validation without errors. If I turn off strict mode for my validator I can, but then it will allow things like ignoring item_count's "minimum": 0 setting.

Here are a few of the errors:

I also had to add in an exception for the keyword "example", but I think that provides a reasonable benefit in the schema.

Ajv package website, in case it's helpful: https://ajv.js.org/

[jhobz]

Turns out the minimum thing is something else (possibly an issue with Ajv, I'm not sure yet), but the errors are still worth fixing. I believe it can be fixed by simply adding "type": "array" to each of the refs above.

[black-sliver]

Not sure if that helps or not, but there already is a reference pack checker here: https://github.com/PopTracker/pack-checker

I think we decided on DRAFT202012 there because it's the latest, but validation also worked with DRAFT7.

If I paste the locations.json schema as data into an online validator and select the Schema Draft v7 or the schema Draft 2020-12, it tells me that no errors were found, so if you think this is an error in the schema, please be more specific where, why and how.

If I turn off strict mode for my validator I can, but then it will allow things like ignoring item_count's "minimum": 0 setting.

You should really use the strict schema for generated code. The lax one is primary for copy-pasta and checking existing packs.

[black-sliver]

Oh, I think I can reproduce your problem with newtonsoft. Looks like the schema is syntactically correct but incoherent maybe?

[black-sliver]

Nevermind. I had a mistake in the JSON that I tried to validate.

If it's reproducible for you, please post the JSON Data that triggers it.

[jhobz]

I initially tried to use the strict schema but the relative reference of maps.json to its non-strict variant complicated my import logic. I do plan to switch back to strict though.

…

On Sun, Apr 12, 2026, 1:43 PM black-sliver ***@***.***> wrote: *black-sliver* left a comment (black-sliver/PopTracker#490) <#490 (comment)> Oh, I think I can reproduce your problem with newtonsoft. Looks like the schema is syntactically correct but incoherent maybe? — Reply to this email directly, view it on GitHub <#490 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANPDJ2Z5Q7OGK4LH6LNFK34VPITXAVCNFSM6AAAAACXWEH6TKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMZSGEYDSOBQGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jhobz]

To be clear when I mentioned strict mode of the validator I meant Ajv's strict mode, not the strict variant of the pack schema. In my previous message I was referring to the pack schema variant though.

I'll lay out some more specifics when I get back to my PC later today; thanks for looking into it so quickly!

[jhobz]

Turns out Ajv "strict mode" (on by default) is actually more strict than the JSON Schema specification. It might be good to meet these stricter requirements anyways, but it probably isn't actually failing the spec, at least. If you are interested, here are the strict mode warnings I got from Ajv (repeated for multiple instances but shown just once here):

That being said...

I've found something else that is also probably up to spec but gives more validators trouble: the use of [property_name]: true to turn an optional property from a referenced schema into a required one -- or at least that's what I'm assuming you're intending with that pattern.

e.g. If you look at the strict maps.json schema, it simply references the loose maps.json schema, then sets "name": true, "img": true, etc. in order to take those optional parameters from the loose schema and require them in the strict schema.

This pattern fails multiple (at least 2) tools. The online Newtonsoft validator passes validation on a map that should fail for not having those required properties. The popular npm package json-schema-to-typescript also fails to pick up this pattern, instead replacing the property definitions for these properties with the value true.

I'm not sure if this pattern is valid JSON Schema or not -- I imagine it is or you wouldn't have thought to write it that way in the first place -- but failing the two most popular google search result tools makes me think it might be best to avoid it. I'll of course log issues with these tools as well (any that I can find bug trackers for, anyways) since they should support this pattern, but it may be worth considering the change.

[black-sliver]

This was actually written by @Cyb3RGER, but as far as I am aware they investigated how to "inherit" those fields, so I believe it is correct.
I also think VSCode, Jetbrains and python-jsonschema all handle this like we expect it to.

If you can suggest a better way to represent this with better tooling support, I am happy to consider changing it.

[jhobz]

I believe it would be as simple as replacing the instances of [property_name]: true with repeats from the lax schema and including them in the "required" array. So I think your strict/maps.json would look something like this (within the "items" node):

"properties": {
    "name": {
      "description": "Identifier for the map.",
      "type": "string"
    },
    "location_size": {
        "description": "Size of locations on the map in pixels relative to the map image.",
        "type": "number",
        "minimum": 0
    },
    "location_border_thickness": {
        "description": "Thickness of the border around the locations.",
        "type": "number",
        "minimum": 0
    },
    "location_shape": {
        "description": "Shape of the map locations.",
        "enum": ["rect", "diamond", "trapezoid"],
        "default": "rect"
    },
    "img": {
        "description": "Image of the map.",
        "type": "string"
    }
},
"additionalProperties": false,
"required": ["name", "location_shape", "img"]

Obviously the repetition of definitions is less than ideal, so you might be able to do something with defs to minimize it, but I tried purely replacing the true lines with "required": ["name","location_shape","img"] in Newtonsoft's validator and it sadly did not seem to work. I'm definitely not an expert in JSON Schema, so it's also possible that there's a simpler alternative that still works properly with tools.

---

Since you mentioned VSCode, I got curious and tested with one of my packs and as you can see here it's actually not validating properly -- it should be showing a linting error here since there is no "img" property. I double-checked and my user settings are indeed validating against the strict schema, which should require it.

[jhobz]

And obviously I'm using maps.json as an example here, but there are other schemas that would benefit from this change as well, arguably even more so in the case of manifest.json (which currently only requires a package_uid despite what the strict schema tries to enforce).

[black-sliver]

Interesting. I believe the schema was originally created with VSCode, so that's why I mentioned it specifically.

I guess at this point it'd be good to hear from @Cyb3RGER . Given how many people use CopilotCode VSCode, I think making it work there is somewhat important.

[Cyb3RGER]

VSCode is working fine with the schema. See manifest.json for example: in the lax version there is required a package_uid and in strict there is just the "package_uid": true which validates completely fine in VSCode:

The confusion stems from the assumption you made about "<property_name>": true make something required, which it doesn't. The strict schema mostly disallows additional properties compared to the lax one.
That being said there could maybe be some more required properties in the schema tho, which probably could also go in the lax schema. Like the img of map for example, or at least I don't know of any reason to have "fake" map.

About the errors from Ajv's strict mode: that looks like it just wants some types from arrays/objects to explicit rather then implicit, which is probably easy to PR with the errors you have.

[jhobz]

Ah, my mistake. What is the intention behind "<property_name>": true then? Wouldn't simply setting "additionalProperties": false on the strict mode achieve blocking additional properties? I do believe it's this behavior of setting to true that's causing issues with the schema-to-types package I'm using. You can see location_size and location_border_thickness get the proper type narrowing from number | string to just number, but the other properties become strict values of true.

(Just copying the image again so that nobody has to scroll to remind themselves)

Happy to PR those changes when I get a chance, sure!

[black-sliver]

I think you may be misunderstanding what the : true is doing.

Our use-case is described here:
https://json-schema.org/understanding-json-schema/reference/object#extending

We say "allOf" some lax object that defines the types and then some strict object (that overrides fields) and says additional properties are not allowed.

However I believe there is actually a bug in our schema: the override should be outside of the "allOf" block, otherwise it doesn't actually override.

[black-sliver]

However I believe there is actually a bug in our schema: the override should be outside of the "allOf" block, otherwise it doesn't actually override.

That being said, it appears that at least python-jsonschema handles it like intended here: https://github.com/PopTracker/pack-checker/blob/64637c6f50777a10e372bdc236ed54ecfd10a30b/tests/checker/test_validate_json.py#L35

(Tests pass, which means validation succeeds on lax and fails on strict)