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 package identity and destination. Do not publish yet.

Import Current and establish the first Draft

Call the adoption operation with the 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 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 Draft. Because the repository has no trusted Typeship-generated baseline yet, the Draft starts at the next major version. Typeship never guesses downward from 0.1.0.

Review the first integration carefully. Typeship accepts files whose contents and file modes match the new Generation exactly. Files that differ, including files present on only one side, require you to choose what to keep. List them with GET /targets/{target_id}/draft/files?filter=conflicted, then resolve selected paths with an explicit side choice, previewed with dry_run: true before saving. Use keep: yours for customer-only tests, workflows, documentation, and licenses. Every decision names a path; an absent generated version means deletion. Typeship continues the Draft after you save every decision. Once the reviewed Draft is merged, later regenerations preserve its non-overlapping custom code normally.

Select a larger unused version in the Console, through PATCH /drafts/{draft_id}, or with the Draft title when the major default is not the version you want:

release: 4.0.0

Typeship refuses a version that is already recorded or lower than the cumulative required bump. An imported release 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 Draft.
4. Require Typeship Release and your package tests.
5. Merge the Draft. Watch the publishing status for each destination in the Target page.

If a registry already contains the selected version with different bytes, do not overwrite or silently accept it. Select a larger version for the Target 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.