Drizzle Team•15mo ago

exclude models from bundle

Hello! I have a monorepo (turborepo + pnpm workspaces) with packages database, schemas & contracts and apps web(nextjs 13 app) & api(nestjs app). Database package hold all the tables, enums & relations definitions using drizzle-orm. Schemas is using the drizzle-zod to create needed body/query schemas. Contracts are ts-rest contracts shared between FE and BE. The problem is that the whole database is transpiled in FE app anyways so you can easily find the table definition in source code. How could that be prevented? (not sure if the problem lays in drizzle-zod, ts-rest or the way that I build the packages as I'm kind of new to this thins)

12 Replies

nightspiteOP•15mo ago

After excluding the database package from client via custom webpack config in next it now won't find the neccessary packages

webpack: (config, { isServer }) => {
  if (!isServer) {
    config.module.rules.push({
      test: /database/,
      use: 'null-loader',
    });

webpack: (config, { isServer }) => {
  if (!isServer) {
    config.module.rules.push({
      test: /database/,
      use: 'null-loader',
    });

nightspiteOP•15mo ago

Patroclazzo•15mo ago

The issue here is the fact that you need the drizzle shemas to generate the validation zod objects to be used in ts-rest. There is no excaping that, you need part of the drizzle library code to be present in the frontend bundle. You can exclude the db driver module since you are not going to connect to a database from the frontend; but other than that I see no solution to this problem. Ts-rest in their examples write the router (with the relative zod schemas) separated (in a specific file or specific lib) form the db and server side stuff (meaning db schema definition), so that code is isomorphic and can run both on the client and on the server. This is an architectural problem, it needs an architectural solution.

Patroclazzo•15mo ago

Our team does not use drizzle-zod package for this reason. The contract between the server and the client is ensured by an series of isomorphic libs that enforce the schema that are separated from the table definition (first solution). It's more verbose, but you don't have to worry about bundle size and bundling issues like this. Another solution could be using something like https://trpc.io/ instead of ts-rest. The fact that you are only exporting the type and not an actual object (meaning the zod validation object) make the import disappears when transpilled in actual js code, so you do not have this problem. (of course you loose the consistency check at runtime on the frontend, but still the dx you are looking for is there)

tRPC - Move Fast and Break Nothing. End-to-end typesafe APIs made e...

End-to-end typesafe APIs made easy. Automatic typesafety & autocompletion inferred from your API-paths, their input data, & outputs 🧙‍♂️

Patroclazzo•15mo ago

Let me know if what I wrote make sense 🙂 PS. I encourage you to try Nx to manage your monorepo. It has a lot more features than turborepo with a nicer (my opinion) dx.

nightspiteOP•15mo ago

Thank you for the response! It totally makes sense and it's what I was afraid of. I will have to drop the drizzle-zod and create separate schemas then. Fortunately in this project it shouldn't be a problem, but in a more complex one that would be a pain in the ass I feel like. (I will spend some time to check, if there is no other solution to that). + Moving things like enums to the schemas package and then importing it in database would probably make sense to have a single source of truth at least for that. Update: I have done some demonic things, just to make sure the types are equal between db and schemas.

nightspiteOP•15mo ago

if the types are not equal it will yell, for these checks

const _insertApiKey: Equals<InternalInsertApiKeyType, InsertApiKeyType> = true;

const _insertApiKey: Equals<InternalInsertApiKeyType, InsertApiKeyType> = true;

nightspiteOP•15mo ago

Patroclazzo•15mo ago

Hi, still me. Not sure that is necessary tho. If you have a zod schema that describe the return and input schema of the api call you should get a type error there without this "demonic things". The db structure could differ from the api contract in the future, keep in mid that.

Gaming

Programming

exclude models from bundle