Closed dBianchii closed 8 months ago
For your particular case of sharing zod schemas, I'd create a separate package for that. For example, React Native doesnt treeshake so you dont even want to have the api package as a production dependency there. So for it to be truly shareable I'd create @acme/validators
For your particular case of sharing zod schemas, I'd create a separate package for that. For example, React Native doesnt treeshake so you dont even want to have the api package as a production dependency there. So for it to be truly shareable I'd create
@acme/validators
Thanks. I created a @acme/shared
package for my use case. Maybe we can close this issue? Unless you have any other thoughts about resource sharing between packages
Maybe we can close this issue? Unless you have any other thoughts about resource sharing between packages
Yea, I'd like to see a concrete use case before adopting such pattern. Marking with server-only means we're locking it down to react RSC only, and as mentioned sharing from separate entrypoint still means you need to include the package with server stuff as a production dep whcih is cumbersome for frameworks not doing treeshaking properly...
I think most things are better shared in their separate pacakge, such as @acme/validators
for validators, @acme/utils
or similar for arbitrary functinos useful on both ends etc etc..
Maybe we can close this issue? Unless you have any other thoughts about resource sharing between packages
Yea, I'd like to see a concrete use case before adopting such pattern. Marking with server-only means we're locking it down to react RSC only, and as mentioned sharing from separate entrypoint still means you need to include the package with server stuff as a production dep whcih is cumbersome for frameworks not doing treeshaking properly...
I think most things are better shared in their separate pacakge, such as
@acme/validators
for validators,@acme/utils
or similar for arbitrary functinos useful on both ends etc etc..
Totally agree. In case I find a reason to adopt this pattern I'll comment again on here. Thanks a lot julius
Describe the feature you'd like to request
Currently with the default setup, you cannot export any resources from
@acme/api
,@acme/auth
@acme/db
to client components in the nextjs app. You can only export types. As soon as you try to export fromindex.ts
any other thing, (for example a shared zod schema, the compiler will yell at you)I suggest we prepare a way for this to be allowed naturally, so we can import any resource from
@acme/api
,@acme/auth
or@acme/db
Describe the solution you'd like to see
I have one suggestion on how to do it, but to be honest, I don't know what is the best way to go about doing this. I'm just going to plop down what I did to make this work. I'd need some more fiddling to make this better/more organized and intuitive
Here's what I came up with:
import "server-only";
directive to it.import "server-only";
export { appRouter } from "./root"; export { createTRPCContext } from "./trpc";
@acme/api
package.json
have the both exports:Additional information
So, this example I have for the
acme/api
package is just to illustrate what I mean. Not necessarily the best way to do it. Don't know how packages normally export both client/server from a single file. I don't even think this is possible,