The "bright" future of my fail

I've been writing my quartet data validation library for a year and a half now. And it was not without fail. The desire to fix them forced me to re-release major versions and change the architecture. And now, for four months now, the last major version has not changed. But it also has its own failures, and now I will try to tell you about them.

The only source of truth and the DRY principle

Let's consider an example:

import { v } from 'quartet' // V ... ...Validation

interface Person {
    id: number
    name: string
    age: number
}

const checkPerson = v<Person>({
    id: v.number,
    name: v.string,
    age: v.number,
})

In this example checkPerson, a function, a custom TypeGuard of type Person.

We can't help but notice the repetitions. The validation description repeats the type description almost completely, but the library does not guarantee in any way that the schema described inside really corresponds to the Person type.

This is not an insoluble problem, there are libraries that have this property, for example io-ts

In this problem, I see a choice between guarantees and the convenience of writing and reading the validation schema. In my opinion, the latter is preferable. But that depends on your tastes and the cost of the mistake.

Explain for invalidity!

Although the explanation mechanism is present, it cannot boast of its abilities. Example

import { e as v } from 'quartet' // E ... ...Explanatory

const checkPerson = v<Person>({
    id: v.number, 
    name: v.string, 
    age: v.number,
})

checkPerson(null) // => false
console.log(checkPerson.explanations) // []

Well, this is some kind of squalor. What kind of explanation is this ??

Let's see if we pass an empty object there:

checkPerson({})

console.log(checkPerson.explanations)

The output will be:

[{ value: undefined, schema: '[Function: number]', id: 'value.id' }]

This is better. But this explanation is not serializable because it schemais a function.

. , .

.

. -? , .

— - . , - , - — .

There are many things that I like about my library that I wrote about earlier: brevity and simplicity , similarity to Typescript , performance .

But now, I thought it was good to write about what went bad and not good enough to be proud of. There are probably some other drawbacks, I will be glad to hear criticism from commentators. And perhaps I will supplement my article.

Thanks for reading