Strategy for sharing runtime-generated schemas from heavy dependencies (e.g., Drizzle) without bundle bloat? (Precompile?)

[crocsinsocks]

Hello,

I am currently generating TypeBox schemas at runtime from my drizzle-orm models. This works perfectly on the backend. However, when used on the frontend (e.g., for form/API validation), it pulls drizzle-orm and the generation logic into the frontend bundle, causing significant dependency bloat.

While my specific use case involves Drizzle, the broader question is: What is the recommended pattern in TypeBox v1 for sharing schemas that are generated at runtime from heavy backend dependencies, without inflating the frontend bundle whilst staying typesafe?

I assume the solution will involve some kind of precompilation or code-generation step to extract the static schemas for the client.

My goal is to keep my code DRY, so I'm hoping someone can advise on the best architectural approach or tooling to solve this generic problem.

Thank you! :)

[rakeshutekar]

The thing that makes this tractable is that a TypeBox schema is inert data. Type.Object({...}) returns a plain JSON Schema object — no class instance, no closure, no reference back to whatever produced it:

{ type: 'object', properties: { x: { type: 'number' } }, required: ['x'] }

So a Drizzle-derived schema contains nothing from drizzle-orm at runtime. Your bundle bloat isn't coming from the schemas — it's coming from the generation module being reachable from a frontend entrypoint. Bundlers follow the import graph, so importing schemas.ts (which imports your Drizzle models, which import drizzle-orm) drags all of it in, even though the resulting value is a few hundred bytes of JSON.

That means you don't need anything TypeBox-specific. You need the generation to happen once at build time, with only its output crossing into the client graph.

The build step

// scripts/emit-schemas.ts   (runs in Node, never bundled)
import { writeFileSync } from 'node:fs'
import { createSchemas } from '../src/server/drizzle-typebox'

const schemas = createSchemas()   // your existing runtime generation

writeFileSync(
  'src/shared/schemas.generated.json',
  JSON.stringify(schemas, null, 2)
)

Wire it into prebuild / a predev hook so it can't drift.

Keeping type safety

This is the part worth thinking about, because there's a real trade-off.

Type.Static<typeof T> works off a phantom type carried on the schema object. Round-tripping through JSON erases that, so a re-imported .json gives you the runtime schema but not the inferred type. Two ways to keep both:

Option A — emit JSON, recover types from Drizzle via type-only imports. Smallest possible bundle:

// src/shared/user-schema.ts
import Schema from 'typebox/schema'
import schemas from './schemas.generated.json'
import type { users } from '../server/db/schema'   // erased at compile time

export type User = typeof users.$inferSelect
export const UserValidator = Schema.Compile(schemas.User)

import type is fully removed by the compiler, so drizzle-orm never reaches the bundler's graph — you get zero runtime cost while staying DRY against a single source of truth. Make sure verbatimModuleSyntax (or isolatedModules) is on so TS doesn't accidentally emit a value import.

Option B — emit TypeBox constructor source instead of JSON. Keeps Type.Static working natively:

// src/shared/schemas.generated.ts  (generated)
import Type from 'typebox'

export const User = Type.Object({
  id: Type.String(),
  name: Type.String(),
  email: Type.String({ format: 'email' })
})

type User = Type.Static<typeof User>

Here the frontend bundles typebox itself (small, and tree-shakes to the constructors you actually use) but not drizzle-orm. You can generate this text by walking the emitted JSON Schema, or just serialize the JSON and wrap it.

I'd default to B if you want a single idiomatic TypeBox story on both sides, and A if the frontend only ever validates and you want to ship literally nothing but data.

Validation on the client

Either way, compile once at module scope rather than per call:

import Schema from 'typebox/schema'

const UserValidator = Schema.Compile(User)

UserValidator.Check(value)   // boolean
UserValidator.Parse(value)   // returns value or throws

Schema.Compile accepts plain JSON Schema, which is precisely why Option A works — the compiler doesn't care whether the schema came from Type.Object(...) or from a .json file.

On drift

The one real risk with any codegen approach is the committed artifact going stale. Two cheap guards: emit into a *.generated.* path that's gitignored and produced by prebuild, or commit it and add a CI step that regenerates and fails on a non-empty git diff. The second is nicer if the frontend and backend are deployed separately, since it makes schema changes visible in review.