Would a developer-friendly DSL layer for JSON Schema align with the organization’s goals?

[shashank-518]

Hi everyone 👋

I recently proposed a GSoC idea about building a developer-friendly DSL (Domain-Specific Language) layer for defining JSON Schemas in the Node.js/TypeScript ecosystem.

The idea is not to modify the JSON Schema specification itself, but to build a thin abstraction layer that:

• Provides a cleaner, less verbose API for defining schemas
• Generates fully Draft 2020-12 compliant JSON Schema
• Optionally generates TypeScript types
• Remains fully compatible with existing validators (e.g., Ajv)

Example:

Instead of writing raw JSON Schema:

{
"type": "object",
"required": ["name"],
"properties": {
"name": { "type": "string" }
}
}

A developer could write something like:

const User = schema.object({
name: schema.string().required()
})

Which internally generates the equivalent JSON Schema.

Before refining this idea further, I wanted to ask:

• Would this type of tooling align with the JSON Schema organization’s goals?
• Or is the current focus more on spec, test-suite, language service, and infrastructure-level improvements?
• If DSL/tooling work is out of scope for the org itself, would it be better suited as an independent ecosystem project?

I’d really appreciate feedback so I can align my efforts with the project’s priorities.

Thank you!

[jdesrosiers]

This already exists (typebox), but feel free to build whatever you think would be useful if you don't think that fits your needs.