SDK Distribution

The generated SDK is plain TypeScript — a frontend in the same repo can import it directly. When the consumers live in other repos (a partner team, an internal microservice, an OSS release), publish it as an npm package.

Set distribute in nestia.config.ts and Nestia stages a publishable package layout next to your generated SDK. Two commands and the package is on npm.

Single-repo SDK? You don’t need this page. Use output: "src/api" and import from a relative path. This page is about publishing.

Configure

nestia.config.ts


import { INestiaConfig } from "@nestia/sdk";
import { NestFactory } from "@nestjs/core";
 
import { AppModule } from "./src/AppModule";
 
const config: INestiaConfig = {
  input:      () => NestFactory.create(AppModule),
  output:     "src/api",
  distribute: "packages/api",   // where the publishable package is staged
};
export default config;

Run:

Terminal


npx nestia sdk

Now packages/api/ contains a self-contained package — package.json, tsconfig.json, the generated SDK sources under ../../api (or relative to your config), and a build script.

Customize the package

The default packages/api/package.json is a placeholder. Edit at least these fields before publishing:

packages/api/package.json


{
  "name":        "@your-org/your-project-api",      // ← rename
  "version":     "0.1.0",                            // ← bump on each release
  "description": "Generated SDK for your-project",
  "main":        "lib/index.js",
  "typings":     "lib/index.d.ts",
  "scripts": {
    "build":     "npm run build:sdk && npm run compile",
    "build:sdk": "rimraf ../../api/functional && cd ../.. && npx nestia sdk && cd packages/api",
    "compile":   "rimraf lib && tsc",
    "deploy":    "npm run build && npm publish"
  },
  "dependencies": {
    "@nestia/fetcher": "^4.2.0",
    "typia":           "^8.0.0"
  },
  "devDependencies": {
    "rimraf":     "^5.0.0",
    "typescript": "^5.4.2"
  },
  "files": ["lib", "package.json", "README.md"]
}

A second tsconfig.json controls how the package is built for distribution (target, module format, declaration files):

packages/api/tsconfig.json


{
  "compilerOptions": {
    "target":     "ES2020",
    "module":     "commonjs",
    "declaration": true,
    "sourceMap":   true,
    "outDir":      "./lib",
    "strict":      true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true
  },
  "include": ["../../api"]
}

Most teams change target and module to match their consumers (ESM vs CJS, modern vs legacy browsers).

If the SDK uses paths aliases (rare; usually for cross-cutting structures), keep them aligned between this tsconfig.json and your server’s.

Publish

Terminal


cd packages/api
npm run deploy            # build + npm publish

Consumers install as a normal dependency:

Terminal (client side)


npm i @your-org/your-project-api

And import:


import api from "@your-org/your-project-api";
 
const article = await api.functional.articles.create(connection, input);

Versioning strategy

Two patterns work well:

Pin to backend version. @your-org/api@1.4.0 means the SDK was generated from the server at tag v1.4.0. Clients explicitly opt into new backends. Use this when you have external consumers.
Track main. The SDK is published on every successful main-branch CI run, with a monotonic version. Use this when both server and client are internal and you want minimal coordination overhead.

Whichever you pick, run npx nestia sdk inside CI before publishing — don’t rely on developers’ machines.

Internal monorepo? Skip this.

If the SDK consumer lives in the same monorepo, don’t publish. Symlink instead — pnpm, yarn workspaces, or bun workspaces mount the local SDK package straight into the consumer’s node_modules. Zero round-trips to a registry.

See SDK → PNPM Monorepo for the wiring.