Hey everyone! AFAIK it's possible to share the gen...
# orm-help
m
Hey everyone! AFAIK it's possible to share the generated Prisma types from the backend with the frontend, but I'm not 100% sure what it would look like in a monorepo with following structure: packages/ • backend/ • frontend/ Would I just create a separate package inside packages/ and use a custom build output .e.g '../models/node-modules/.prisma/client'?
s
Hey @Marvin! I actually recently wrote an article on exactly this: https://sabinadams.hashnode.dev/end-to-end-type-safety-what-why-and-how Let me know if that helps at all
In the case of a monorepo, another option would be like what you said, to generate the client into a package and share it. I know Nx has trouble bundling the Prisma output files, so storing in a package won't work in that case. A way to get around that would be to generate into node_modules as usual and expose them through a package by just exporting.
Copy code
// /packages/prisma/index.ts

export * from '@prisma/client'
m
That looks good, I will try that. Thanks a lot! 🙂
s
Sure thing!
a
I've got a yarn2 workspace where I export data types in my back-end, and share with my front-end, which is a separate React app. It's a big of a slog to get the config working right, but super useful once it's up and running.
One warning on Prisma types: you may not want to share directly, because there are scenarios where your front end shouldn't have access to certain back-end only fields
an obvious case is something like a hashedPassword field. And most complex apps will have other fields that are important on your back-end but not intended to share with your front-end. You may wind up wanting to share output/DTO types from your Back-End that are similar to, but not exactly the same as, your Prisma types.
n
It’s a big of a slog to get the config working right, but super useful once it’s up and running.
Hey Austin, that sounds really awesome! Not sure if you’re into blogging but I think this could be a great blog post to help out other devs with this setup in the future 😄
👍 2
❤️ 1
s
I'd definitely be curious to see this in action plus one +1
m
@Sabin Adams I'm just checking out your suggestion to just expose the types via a packages/prisma package but what would I define for the
main
and
types
field in the `package.json``? It looks like it needs both? Isn't it possible to just export the types without any runtime code?
The package only has a dependency to
@prisma/client
and a
packages/prisma/index.ts
with
export * from '@prisma/client'
When I add
@prisma/client
as a dependency to
packages/frontend
without any separate package, I can import the types in my frontend code from
.prisma/client
but not
@prisma/client
(error: has no exported member XXX).
s
Hey Marvin! .prisma/client is the correct location 👍 My bad!