Hi @chaudhariamanullah! I'm Dosu and I’m helping the zod team.

I'm a bot trained on Zod's codebase and community discussions. The most maintainable pattern is to use Zod schemas as your single source of truth for API validation and TypeScript types. Define your Zod schema in a shared file, then use z.infer<typeof schema> to extract the TypeScript type for use in your service layer—this avoids duplicating type definitions and keeps everything in sync source, discussion.

For your database models, it's often best to keep separate TypeScript types (for example, those generated by your ORM) because API request shapes and DB table shapes can differ—fields might be optional in the DB but required in the API, or you might have calculated fields in the DB that don't exist in requests discussion.

If you find yourself duplicating enums or constant values, define them as a const array and use that for both your Zod schema and your TypeScript type example:

const statusValues = ['active', 'inactive'] as const;
type Status = typeof statusValues[number];
const StatusSchema = z.enum(statusValues);

There are community tools like toZod that try to generate Zod schemas from TypeScript types, but they have limitations and aren't perfect for complex cases discussion.

If you want more tailored advice, let me know what ORM or DB tool you're using and how you currently share types between layers. If this helps, feel free to close the issue!

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}