typeName is the name of the type you want to register. The type declaration must be in the same scope of the call to registerType.

`typescript
{
type A = {val: string}
registerType('A') // registers A
{
registerType('A') // does nothing :(
}
}
registerType('A') // does nothing :(
`

All registered types are stored in a per-file global namespace. This means any types you want to register in the same file should have different names.

registering a type in one file will not allow it to be accessible in another file. This means you cannot generate validators for multi-file types
(a type that references a type imported from another file). If this is a big issue for you, go to the "Caveats" section.

A work-around for supporting multi-file types is to move your multi-file types into one file (so they are no longer multi-file types). Then generate the validation
functions in that file and export to them where you want to use them. This works because validation functions are just normal Javascript!

registerType automatically registers all types in the same scope as the original type it is registering that are referred to by the original type.

`typescript
type A = {val: string}
type B = {val: A}
type C = {val: A}
// registers A and B, but not C, since B only refers to A.
registerType('B')
`
All instances of the registerType macro are evaluated before any instance of createValidator. So ordering doesn't matter.

Most of the primitive types (string, number, etc.) are already registered for you. As are Array, Map, Set and their readonly equivalents.

$3

T can be any valid Typescript type/type expression that is supported by the macro.

At compile time, the call to createValidator will be replaced with the generated code.

#### BooleanOptions: {circularRefs?: boolean, allowForeignKeys?: boolean}
- allowForeignKeys
- Default: true.
- If false, then any unexpected/extra keys in objects will throw a validation error. Note: If you are using a string index signature then there is no such thing as an extra key. And if you are using just a numeric index signature, then there is no such thing as an extra key with a numeric value. This is consistent with typescript.
- circularRefs
- Default: true
- If false, then any circular references in the object will result in an infinite-loop at runtime. Note: circular types, such as type A = {next: A } | null will still work if this option is set to false. However, true circular references (instead of just another layer of nesting) in an input object will not work.

$3

Full type signature:
`typescript
function createDetailedValidator(
opts?: DetailedOptions
): (
value: unknown,
errs: Array<[string, unknown, IR.IR | string]>
) => value is T;
`

Creates a detailed validator function for the type T. Example usage:

`typescript
const v = createDetailedValidator<{x: string}>()
const errs = []
const result = v({x: 42}, errs) // result is false
// errors = [["input["x"]", 42, "type: string"]]
`

The resulting validation function takes 2 parameters:
- value, the value you want to validate
- errs, an array which will be populated with all the validation errors (if there are any). Each entry in errs is a tuple of 3 elements:
- the path in the object at which validation failed (string)
- the value at that path (any)
- the expected value at that path

#### DetailedOptions: BooleanOptions & { expectedValueFormat: string }
- expectedValueFormat
- Default: "human-friendly"
- If "human-friendly" then the expected value format will be a human friendly description of the types.
- If "type-ir" then the expected value will be a JSON object representing the macro's internal representation of the expected type. It is not recommended to use this option because the internal representation is unstable and not bound by semver.

Constraints

What if you want to enforce arbitrary constraints at runtime? For example, ensure a number in an interface is always positive. You can do this with constraints. You can enforce an arbitary runtime constraint for any user-defined type (e.g not number, string, etc.).

The type of the 2nd parameter of both createValidator and createDetailedValidator:

`typescript
type UserFunction = { constraints: { [typeName: string]: Function } }
`

$3

`typescript
const x = createValidator(undefined, {
constraints: {
Positive: x => x > 0
}
})
`

Notes:
- The Positive key in the constraints object corresponds to the user-defined type Positive.
- The value must be a function expression. It cannot be a variable that refers to a function because the macro is evaluated at compile time.
- The constraint is only called after its base type has been validated. In this instance, the "Positive" constraint will only be called after input.pos is validated to be a number.

$3

`typescript
const x = createDetailedValidator(undefined, {
constraints: {
Positive: x => x > 0 ? null : "expected a positive number"
}
})
`

Note: The constraint function returns an error (if there is one). Otherwise it returns a falsy value. Any truthy value will be treated as an error message/object.

Support Tables