Adopt an existing package

Use adoption to keep an existing package's registry name and released baseline while moving future generation to Typeship. Typeship verifies the published version and prepares a Draft for your review. Adoption does not guarantee that generated code preserves your existing SDK interface; compare it before merging.

Before generating

Record these facts from the existing package:

• registry or Go module identity
• latest published stable and prerelease versions
• repository and package directory
• public entry points and executable names consumers use
• current publishing workflow, trusted-publisher settings, and protected environments

Create an unreleased Target with that exact identity and destination. Do not publish yet.

Import Current and establish the first Draft

Call the adoption operation with the exact published version and its immutable repository tag:

curl -X POST https://typeship.dev/api/v1/targets/tgt_.../adopt \
  -H "Authorization: Bearer $TYPESHIP_API_KEY" \
  -H "Idempotency-Key: adopt-package-3.7.2" \
  -H "Content-Type: application/json" \
  -d '{"version":"3.7.2","tag":"sdk-v3.7.2"}'

Typeship resolves the tag to an immutable commit, verifies the package metadata at that commit, and confirms the exact npm, PyPI, Go, and, when applicable, MCP Registry version exists. It records an Imported Current release with the tag, commit, registry URL, and artifact digest as provenance. A branch name or an unverified package is rejected.

Typeship then opens the first rolling Draft. Because the repository has no trusted Typeship-generated baseline yet, the handoff Draft starts at the next major version. Typeship never guesses downward from 0.1.0.

Review the first integration carefully. Because an imported package has no trusted Previous Generation snapshot, Typeship reports a missing-baseline conflict instead of guessing which existing files are generated or custom. Resolve those paths on the rolling Draft or reset selected paths to the next Generation. Once that exact combined commit is accepted, later regenerations preserve its non-overlapping custom code normally.

Select a larger exact unoccupied version in the Console, through PATCH /targets/{target_id}/draft, or with the Draft title when the major default is not the intended handoff:

release: 4.0.0

Typeship refuses a version that is already recorded or lower than the cumulative required bump. Imported Current remains distinct from Typeship-generated releases in release history.

Transfer publishing

1. Stop the old automation from publishing new versions.
2. Configure npm or PyPI trusted publishing for .github/workflows/typeship-release.yml in the destination repository.
3. Enable Publish after merge on the Target and review the workflow files added to the same rolling Draft.
4. Require Typeship – release readiness and your package tests.
5. Merge the exact Draft. Watch the independent Publication states in the Target page.

If a registry already contains the selected version with different bytes, do not overwrite or silently accept it. Return the Target to a larger exact version and regenerate.

Roll back the automation

Disable publish on merge to remove the Target's trigger manifest in a reviewed Draft. Existing releases and registry packages remain immutable. Your previous release system can resume from the next unused version.

If consumers need a custom interface, use Customize generated packages to add reviewed package changes or maintain an independent wrapper. Adoption preserves registry identity and release history; you still need to assess compatibility with a handwritten interface.