Add a package to your repo

Where a generated package goes in your repository, how to depend on it, and how to build it. For projects with a destination configured, the pull request already did this.

A generated package is a complete package for its ecosystem: readable source, zero runtime dependencies, and a build. This guide covers placing one by hand. When a project has a destination configured, typeship's pull request puts the package in place, one per language, and updates it on every spec change, so most of this page is only for downloaded zips.

Where to put it

In a monorepo with workspaces: packages/acme.
In a single-package repository: vendor/acme.
Any path works. The import name comes from name in the generated package.json, not from the directory.

Depend on it

As a file dependency:

npm install ./vendor/acme
# or
pnpm add ./vendor/acme
# or
yarn add file:./vendor/acme

Or as a workspace member:

package.json

{ "workspaces": ["packages/*"] }

apps/api/package.json

{
  "dependencies": {
    "acme": "*"
  }
}

Installing also puts the package's bins on your PATH when those platforms were generated: acme for the CLI and acme-mcp for the MCP server.

Build it

The package ships as TypeScript source and must be compiled before anything imports it. main, types, and exports point into dist/:

cd vendor/acme
npm install     # typescript and @types/node, dev only
npm run build   # tsc -> dist/

After the build, dist/ holds the compiled JavaScript, .d.ts declarations, and declaration maps, so editors jump from your code into the package's source.

ESM only

The package declares "type": "module" and its exports map exposes an import entry only. require() is not supported.
Node 18 or newer.
Works with modern bundlers. It is tree-shakeable: one module per resource and "sideEffects": false, so bundlers drop the resources you never call.

Keep custom code outside the package

Regenerating replaces the entire package. Never put your own code inside it. Wrap the client in a module you own. See Extend the client.