TypeScript Academy · Lesson

Shared Types Package Strategy

Create a dedicated types package consumed across the monorepo.

Shared Types Package Strategy is a free TypeScript Academy lesson on CoddyKit — lesson 3 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the TypeScript Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Why a Shared Types Package?

Sharing types across frontend and backend eliminates drift between API contracts. A single source of truth means compile-time errors when the API shape changes.

// packages/types/src/index.ts
export interface User { id: string; name: string; email: string; }
export interface ApiResponse<T> { data: T; error?: string; }

Package Structure

Keep the types package minimal: just type exports, no runtime logic. This keeps it side-effect-free and tree-shakable.

packages/types/
├── src/
│   ├── index.ts      # re-exports all
│   ├── user.ts
│   ├── product.ts
│   └── api.ts
├── tsconfig.json
└── package.json

tsconfig for a Types Package

Enable emitDeclarationOnly so no JavaScript is emitted — only .d.ts files that consumers reference.

{
  "compilerOptions": {
    "composite": true,
    "declaration": true,
    "emitDeclarationOnly": true,
    "outDir": "./dist",
    "rootDir": "./src"
  }
}

Consuming the Types Package

Reference the types package in both the API and web app, and import types with import type to avoid runtime overhead.

import type { User, ApiResponse } from "@myapp/types";

async function getUser(id: string): Promise<ApiResponse<User>> {
  // ...
}

Keeping Types Serialization-Safe

Types shared between client and server should only include JSON-serializable values. Avoid Date objects — use string (ISO) instead.

// Good: serialization-safe
interface Event { id: string; createdAt: string; /* ISO date */ }
// Bad: Date is not JSON-serializable
interface Event { id: string; createdAt: Date; }

Versioning the Types Package

Version your types package with semver. A breaking change (removing or renaming a field) is a major version bump.

# Breaking change: major bump
npm version major
# Adding optional fields: minor bump
npm version minor

Generating Types from OpenAPI

Automate the types package by generating it from an OpenAPI spec using openapi-typescript. This guarantees the types always match the backend.

npx openapi-typescript ./api/openapi.yaml -o ./packages/types/src/api.ts

Using Zod for Runtime + Compile-Time Types

Define types with Zod schemas and infer TypeScript types from them. Both the runtime validation and static types come from the same source.

import { z } from "zod";
export const UserSchema = z.object({ id: z.string(), name: z.string() });
export type User = z.infer<typeof UserSchema>;

Avoiding Circular Dependencies

The types package should not import from other workspace packages to prevent circular dependency chains. Keep it a leaf node in the dependency graph.

// types/ should not import from ui/ or api/
// ui/ and api/ both import from types/

Testing Type Correctness

Use tsd to write type-level assertions that verify the shared types match expectations.

import { expectType } from "tsd";
import type { User } from "@myapp/types";
expectType<User>({ id: "1", name: "Alice", email: "a@b.com" });

Recap: Shared Types Strategy

A shared types package eliminates API drift: emit declarations only, keep types JSON-serializable, version with semver, optionally auto-generate from OpenAPI, and test with tsd.

Quick Check

Why should shared API types use string instead of Date?

What You Learned

A shared types package is a single source of truth for API contracts. Keep it declaration-only, JSON-safe, versioned with semver, and optionally generated from OpenAPI to eliminate drift between frontend and backend.

Frequently asked questions

Is the “Shared Types Package Strategy” lesson free?

Yes — the full text of “Shared Types Package Strategy” is free to read here on the web, and the TypeScript Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the TypeScript Academy course, upgrade to CoddyKit PRO.

What will I learn in “Shared Types Package Strategy”?

Create a dedicated types package consumed across the monorepo. You practise TypeScript Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start TypeScript Academy?

No prior experience is required. TypeScript Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 3 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Shared Types Package Strategy” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this TypeScript Academy lesson?

Yes. Every TypeScript Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

TypeScript Project References Explained
pnpm Workspaces with TypeScript
Shared Types Package Strategy
Incremental Builds and Cache in Monorepos

← Back to TypeScript Academy