shared-libraries-guidelines

Standardize TypeScript types and validation by centralizing shared types, Zod schemas, and utilities in dedicated packages (@quantum/shared-types, @quantum/shared-validation, @quantum/shared-utils). Define types first, then derive Zod schemas from them, and export all definitions from index files to create a single source of truth across your monorepo.

Separate database and application types by maintaining distinct type definitions in your shared libraries—DB schemas map to database models, application types represent domain logic. This prevents type leakage and ensures safe transformations between layers while keeping validation contracts explicit.

Create reusable enum schemas in @quantum/shared-validation by defining TypeScript enums first, then generating corresponding Zod schemas that validate against those enums. Export schemas centrally so all consuming applications reference the same validation logic and maintain consistency.

Yes. Shared TypeScript libraries enable cross-project contracts by centralizing types, validation schemas, and utilities consumed across frontend, backend, and data-access layers. This requires consistent naming conventions, clear DB-vs-App separation, and integration with your monorepo build workflow.

Follow consistent naming conventions documented in your shared libraries guidelines—use clear, predictable names for types, schemas, and utilities exported from @quantum/shared packages. Consistent naming reduces cognitive load across teams and prevents drift when multiple projects depend on the same contracts.

Integrate shared libraries by building and publishing @quantum/shared packages centrally, then updating consuming applications when breaking changes occur. Document integration steps and use centralized exports to ensure all teams adopt updates consistently across the monorepo.