#TSOA generating from @prisma/client

9 messages · Page 1 of 1 (latest)

dapper oak
#

This is my current workflow, i run tsoa spec-and-routes with OpenAPI to generate a swagger.json of my controllers. In my controllers, i use models from @prisma/client generated from schema.prisma. I fairly sure this is how it works.

The issue is when i go into, for example, import {User} from @prisma/client, this is the definition... and i think TSOA does not understand this type

 * Model User
 * 
 */
export type User = runtime.Types.DefaultSelection<UserPayload>```

This was working before until recently. 

How can I maintain type safety without have to recreated this type? Or what is your approach to auto generating an 'api-client' for use on the client side?
dry lichenBOT
#

You chose to compile with the bot. One moment while I piece together your answer…

dry lichenBOT
# dry lichen You chose to compile with the bot. One moment while I piece together your answer...

Based on the knowledge sources provided, I can offer some insights into your question about TSOA generating from @prisma/client and maintaining type safety.

The issue you're experiencing with TSOA not understanding the type definition from @prisma/client is a known challenge when working with Prisma's generated types and other tools that rely on more straightforward type definitions.

To address this issue and maintain type safety without recreating types, there are a few approaches you can consider:

  1. Use Prisma's helper types:
    Prisma provides helper types that can be used to create more specific type definitions. As described in the Prisma docs on operating against partial structures of model types, you can use Prisma.UserGetPayload to create a type that includes all fields of the User model:

    import { Prisma } from '@prisma/client'
    
    type UserWithAllFields = Prisma.UserGetPayload<{}>
    

    This approach allows you to maintain type safety while providing a more concrete type definition that TSOA might be able to understand better.

  2. Create a type based on Prisma's generated type:
    You can create a new type based on the Prisma-generated type, which might be more compatible with TSOA. For example:

    import { Prisma } from '@prisma/client'
    
    type User = Prisma.UserGetPayload<{
      select: { id: true, email: true, name: true } // Include all fields you need
    }>
    

    This approach allows you to explicitly define the structure of the User type while still basing it on Prisma's generated type.

  3. Use a custom output for Prisma Client generation:
    As mentioned in the Prisma docs on type safety, you can customize where Prisma generates its types. This might allow you to generate types in a format that's more compatible with TSOA

dry lichenBOT
# dry lichen You chose to compile with the bot. One moment while I piece together your answer...

.

As for generating an API client for use on the client-side, one approach is to use GraphQL with Prisma. The Prisma blog post on end-to-end type safety describes how you can use GraphQL codegen to generate types based on your API schema, which can then be used in your client-side code.

If you're not using GraphQL, you might consider using OpenAPI/Swagger codegen tools to generate a client based on your TSOA-generated swagger.json file. This would allow you to maintain type safety between your API and client while leveraging the types generated by Prisma on the server-side.

Remember that the exact solution might depend on your specific setup and requirements. You may need to experiment with these approaches to find the one that works best for your project.

dry lichenBOT
dapper oak
#

I'm already using OpenAPI/Swagger codegen tools to generate a client

dapper oak
native ingot
#

This was working before until recently.
Do you mean it started breaking after a prisma version upgrade?