SDK development
- TypeScript
- Turborepo
- Nx
- pnpm
What does SDK development cover?
SDK development for a TypeScript package other people install, versioned from a monorepo with Turborepo or Nx.
The public core is the package. Types are the contract. A monorepo holds the packages that move together. Turborepo runs what changed. Nx does that when the graph needs affected builds and a boundary a package cannot cross. A video room, a WebRTC path, or an AI call is one kit you might publish. The trade is the same for a chat kit or a payment sheet.Discuss this capabilityThe work
The package is the product.
The offer that circulates is a folder named sdk. Copy the helpers into the app. Call it a platform. The next team cannot install it, the types lie, and a second publish ships the same version twice.
The public core is the package a stranger imports. Its types are the contract. A function that is public in the README and private in the types is not an API. The demo app stays out of that package. A breaking change is a version, not a quiet edit on main.
A monorepo holds the packages that must move together: the core, the bindings, the types, the sample. One lockfile. One place a peer dependency is declared. Turborepo is the task runner. It caches the build and the test, and it runs what changed. Nx is the same job when the graph is large: affected projects, generators, and a boundary the module cannot cross. We pick one. Two task runners in one repo is a second source of truth.
The release is the part people skip. Semver matches the diff. A changeset names the packages. The token that publishes can expire. A retry must not create a second version of the same commit. pnpm is the install we use when the workspace and the peer dependencies have to stay honest. A private registry is the destination when the kit is not public.
A video room, including a product such as VideoSDK, is one kit in this shape. WebRTC is the path under it when you host the media. An AI calling kit is the same package with a model on the line: a phone number, a button in the app, or a room with the agent in it. A chat kit, a payment sheet, or a map pin is the same trade. The package boundary does not change because the feature is a call. The engineers who ship the app also ship the package, on the same release.
Best for Teams shipping a kit other developers install, not a one-off folder inside a single app.
Core capability
- TypeScript packages with a public contract
- Monorepos on Turborepo or Nx
- Versions, changesets, and a registry
- A video, calling, chat, or payment kit in that same shape
What moves forward
- The package other developers install
- One task graph, and the boundary it enforces
- A release that publishes each change once
How we approach it
One public contract.
- 01
Draw the package boundary
Name what another team imports. The demo app is not in that package. A second entry point for the same job is a decision.
- 02
Make the types the contract
Public functions have public types. A peer dependency is declared, not bundled by accident. A type that only works inside this repo does not ship.
- 03
Pick the graph runner
Turborepo when the cache and the pipeline are the problem. Nx when the repo needs affected builds and a boundary a package cannot cross. One runner.
- 04
Publish once
Semver matches the change. The changeset names the packages. A retry does not publish the same commit again. The sample installs the package you just shipped.
SDK development
Make the next decision concrete.
Share the outcome, constraints, and current system. We’ll help identify the right starting shape.