No.
Imagine a Zod schema like:
const UserLocation = z.object({ address: Address, coords: Coords })
where Address, Coords are other zod schemas.
Now if I infer a type like:
type IUserLocation = z.infer<typeof UserLocation>
Th inferred IUserLocation is something like:
type IUserLocation = { address: { city: string, country: string, ... }, coords: { lat: string, long: string } }
The extracted type does not refer to separate Address, Coords type, it is a single complex type that represents the complete nested structure.
So if I do something like:
const userLocation: IUserLocation = { address: { ... }, coords: { lat: 0, long: 0 }}
The error message is complex because it (effectively) says that coords.lat was expected to be a string from IUserLocation["coords"]["lat"] but it was number
However, if I define a ts interface directly:
interface IUserLocation {
address: IAddress
coords: ICoords
}
now any errors reported against this interface will be more comprehensible because they will (effectively) say that coords I am providing does not comply with ICoords.
This is a contrived example, but this becomes more complex when you have deep compositions of zod types.
This issue of typescript not using well named intermediate types when types are "extracted" from schema definitions like zod is what makes the error messages complex.
This would not apply if typescript was to provide runtime type checking for interfaces defined in typescript (as opposed to them being inferred) because ts will have a way to "know" about these intermediate types. Then the type errors would not have to be always reported against the complex top level type.