What is the scope of this project?

[GabenGar]

Judging by the readme it looks like it's going to be THE json schema validator and API surface is similar to AJV, however it misses some important AJV features:

• codegen
• non-strict validation

Both are pretty important for the actual uses on the web, so I would like to know if they are planned/there are other specialized packages for these things.

[jdesrosiers]

The goals of this project are a bit different than those of ajv. Ajv's primary objective is fast validation. My primary objective is supporting tooling. If someone wants to create their own dialect of JSON Schema (custom keywords, etc), or create non-validation JSON Schema tools such as a form or documentation generator, this library is intended to be tools to make that work easier. The validation functionality had to come first, but it's intended to be just one thing that can be built on this library. The tools for supporting non-validation tooling mostly isn't ready yet, but that's the vision.

I'm not sure what you mean by "codegen". Usually people use that word to mean generating types from schemas, but as far as I know, ajv doesn't do that. In ajv, "codegen" refers to generating a validation function. This library does something similar. Instead of compiling to a JavaScript function, it compiles to an abstract syntax tree (AST). Validation is done by interpreting the AST. Interpreting an AST is slower than a raw JavaScript function, but this architecture is more powerful because it allows for other types of tooling to be built against the AST. One of those tools could be to interpret the AST into a JavaScript function or code in any other language. If you meant the other meaning of "codegen" (generating types), that's something that could be built from the AST as well.

I expect that you meant "strict validation" rather than "non-strict validation"? "Strict mode" is a proprietary ajv concept and is not compatible with the JSON Schema specification. I will not be emulating that functionality. The rules ajv implements in its strict mode are poorly thought out and in many cases harmful for writing good schemas. The goals of "strict mode" are reasonable, but I think it's the wrong solution. What's really needed is a linter. I'm hoping to at some point use this tooling to build an eslint plugin that lints schemas.

[GabenGar]

By codegen I meant literal codegen. Generating standalone code is pretty useful for lambda functions such as NextJS, since they tend to deal with only a small subset of schemas during their lifetime.
And by non-strict validation I meant the coerceTypes option. It is useful for validating the likes of URLSearchParams/FormData, which are the main sources of input data on the web.
But both of these can be derived from AST I guess, since parsing various types of references is the most painful part of schema-related ad-hoc solutions in my experience.

[jdesrosiers]

And by non-strict validation I meant the coerceTypes option.

Ah! That makes more sense and you're right that that's a useful feature.

But both of these can be derived from AST I guess

Yep. That's the idea. I wouldn't implement something like coerceTypes as a validation option, I'd implement something that coerces the types based on the schema AST. Then you can pass the result to the standard validate function. There are a number of similar schema based value transformation utilities I have in mind such as filling in default values and removing additional properties.