ts-mockit

The types you already wrote, turned into a working mock API.

---

Introduction

You already write TypeScript interfaces. ts-mockit reads them and spins up a real local API returning realistic fake date that matches your types exactly - no manual JSON, no hand-roplled mock server, no waiting on the backend.

npx typemock-api hard-example.ts

export interface User {
    id: string;
    name: string;
    email: string;
    age: number;
}

mockit server running at http://localhost:4000
 
GET  /user        → 20 fake users
GET  /user/0      → one fake user 

Note: :index is a placeholder. Replace it with the item index you want to access, e.g. /post/0, /post/1, or /post/2.

That's it!! Your frontend now has a real endpoint to build against, today.

How it works

ts-mockit uses the TypeScript compiler itself to stastically read your file - the same way tsc does - and walks the actual type graph, not a regex or a guess. Every interface, nested object, array, enum and unions gets reduced to a shape then handed to a data generator that produces realistic values based on both the type and the field name.

interface User {
    id: string;
    email: string;
    age: number;
    role: "admin" | "editor" | "viewer";
}
// ****
{
    "id" : "b21e11d7-ddb0-44ec-ac93-c5e1a4d5ce4a",
    "email": "brian.sanford@hotmail.com",
    "age": 34,
    "role": "editor" 
}

Features

Field-aware generation - a string field named email gets a real-looking email not random words. age gets a sane range. price gets a realistic decimal. The generator reads intent from your field names not just their types.

Full-recursive support - nested objects, array of objects, enums, unions, and dates are all walked correctly, however deep they go.

interface Post {
    role: "admin" | "editor" | "viewer";
    address: { street: string; city: string };
    comments: Comment[];

    // all resolved correctly - nested objects stay objs
    // arrays stay arrays, enum pick a real member
}

Resolves import across files - if yur type import another type from a different file, ts-mockit follows it automatically, because it uses the real TypeScript type checker, not a single file parser.

import { Address } from "./address";

export interface User {
    homeAddress: Address; // resolved correctly, from anywhere in your project
}

Stable data per session - data is generated one when the server starts and cached, so your frontend isnt fighting new random values every refres.

Zero config, zero setup - one command, one file, no config file to write :3

Usage

npx typemock-api <file> [options]

Option	Description	Default
-p, --port <number>	Port to run the server on	4000
-c, --count <number>	Fake records generated per type	20

every exported interface or type in the file become its own route, named after the type(lowercased):

GET /<type>          → all fake records
GET /<type>/:index   → one record by index

Why not just write JSON by yourself?

You already do the type design work once, In typescript, ts-mockit reads that instead of asking you to describe your data twice once in code, once in a mock file that drifts out of sync with the real types.

License

MIT