[solumunus]

This doesn’t solve the problem.

If I have a user type, inferred from a Zod schema:

> { username: string; email: string }

And a function which takes that type:

> storeUser(user: User)

There is absolutely nothing that guarantees that the user object has been parsed by Zod. You can simply:

> storeUser({ username: “”, email: “no” })

And Typescript will not shout at you.

The only way to comparably solve it with Typescript is to inject a symbol into the object during parsing which confirms it has been passed through the correct parser function.

Personally, I just do basic type parsing on input data (usually request data) and more strict parsing where constraints like “is this a valid username, is this a valid email” during output (usually sending to the database). What happens in between I/O doesn’t matter much in many projects (CRUD), and in the places it does you can enforce more rigidity.

[WuxiFingerHold]

Depends on what the problem definition is. If it's having an as bullet proof solution as possible, you're of course right.

But there are simpler and cheaper solutions that might be good enough.

I guess my intention was also to point out that there're mature frameworks for many languages, but somehow most people in the Go community keep reinventing the wheel and unfortunately more often worse than better. Some years ago I wrote a Go web service. Of course I found the first two versions of OPs series. They're great to read and even greater to watch on YT, but I preferred the approach ardanlabs (Bill Kennedy). It was for sure interesting going through all of this, but incredible time consuming.

[angra_mainyu]

Well, I use ajv and they have ways of applying format validation, so not just saying: "this is a string", but rather, "this is a string and must be a valid domain name".

Now, if your complaint is rather that you can call whatever method and pass in your bogus data, I don't see the point in arguing that. It's your code, the only person who can stop you is you.

[solumunus]

> Now, if your complaint is rather that you can call whatever method and pass in your bogus data

This entire comment thread is a discussion about how to prevent that from being a possibility. The person I responded to threw their hat in with a Typescript solution that doesn’t achieve the goal being discussed. I was simply pointing this out.

[WuxiFingerHold]

>> I've found validators to be much more error-prone than leveraging Go's built-in type checker.

>This entire comment thread is a discussion about how to prevent that from being a possibility.

No, this thread is also about how much you need to invest to be safe enough, when time and resources are limited.