enhance(build): validate built data.json against schemas

[caugner]

Summary

1. Validates the built data.json against the schemas.
2. Removes the maxProperties requirement for the browsers object from the browsers schema.

Test results and supporting details

This revealed two minor issues:

1. The browsers schema was requiring a maximum of one browser defined in browsers. This requirement only applies to the individual browser/*.json files, not the built data.json, so this requirement was removed.
2. The __meta object in the built data.json is not currently covered by the schema, so we cannot validate it.

Related issues

Fixes #27564.

[github-actions]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[caugner]

Note

If validation fails, the validation errors are logged via console.error, but we don't bail out, to avoid disruption for contributors in the unlikely event that this ever happens on main. In either case, these errors won't get unnoticed, because they will appear on every npm install (via the prepare script).

[ddbeck]

Does this mean that a PR that breaks schema validation won't fail the build? I can kinda see the case for never failing during the prepare script, but it'd be nice if there were a test that does fail. I won't block on this though, as it would be a step up from what we have.

[caugner]

How about checking process.env.CI and failing if we're in CI?

[ddbeck]

That would help for local development, but not pull request checks. Maybe check if GITHUB_REF is refs/heads/main and, if true, convert errors to warnings, else do nothing?

[caugner]

In pull request checks, we always have CI=true in the environment, so we would notice it in a PR before merging. (In fact, the PR check would fail, preventing a merge.)

[caugner]

Let's tackle this afterwards.

[ddbeck]

• The __meta object in the built data.json is not currently covered by the schema, so we cannot validate it.

FWIW, I raised this as a concern in #17574 and got shot down on doing anything about it.

[caugner]

FWIW, I raised this as a concern in #17574 and got shot down on doing anything about it.

FWIW, here's the meta schema (isolated, like the other two):

{
  "$schema": "http://json-schema.org/schema",

  "definitions": {
    "meta_block": {
      "type": "object",
      "properties": {
        "timestamp": {
          "type": "string",
          "format": "date-time"
        },
        "version": {
          "type": "string"
        }
      },
      "required": ["timestamp", "version"],
      "additionalProperties": false
    }
  },

  "properties": {
    "__meta": {
      "$ref": "#/definitions/meta_block"
    }
  },

  "title": "MetaData",
  "type": "object",
  "required": ["__meta"],
  "additionalProperties": false,
  "maxProperties": 1,
  "minProperties": 1
}

Unfortunately, ajv gives me an error when validating the data:

TYPE must be string

  2 |   "__meta": {
  3 |     "version": "7.1.0",
> 4 |     "timestamp": "2025-08-28T14:30:46.924Z"
    |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^ 👈🏽  type must be string
  5 |   }
  6 | }

That error doesn't make sense, but given this is not a priority, I would declare the scope of this PR to validate the built data against the existing schemas.

[caugner]

@queengooborg If we can get this in, we can split up the schema into internal/public, and validate separately. Currently, it's a mix of both.

[Elchi3]

Approving the schema change 👍

[ddbeck]

I've reviewed the code. Thank you!

[ddbeck]

See also 😒 #17574

[caugner]

See also: #27685 (comment)

[ddbeck]

Does this mean that a PR that breaks schema validation won't fail the build? I can kinda see the case for never failing during the prepare script, but it'd be nice if there were a test that does fail. I won't block on this though, as it would be a step up from what we have.

Approved by @argl