ts-sdk-author

TypeScript SDK 作成者

pnpm モノレポ内から、スタンドアロンの npm パッケージとして TypeScript SDK をリリースするためのエンドツーエンドのワークフローです。ワークスペースの構成、パブリック API の設計、ビルド設定、配布形式、モノレポのパイプライン、検証、ベータ版／RC／カナリアチャンネルを含むリリースライフサイクル全体を扱います。

詳細は7つのリファレンスにまとめられています。このファイルでは、統一されたワークフローと、日々活用するパターンのクイックリファレンスを紹介します。

---

このスキルを使用する場面

• 既存の CLI やアプリから、pnpm ワークスペース内に中核ライブラリ（例：packages/core、packages/sdk）を切り出す場合
• 他の開発者が利用する TypeScript ライブラリのパブリック API を設計する場合 — ブランド型、ジェネリッククライアント、プラグインの拡張ポイント
• ビルドツールを選ぶ場合 — tsdown、tsup、tsc のみ、unbuild
• デュアル ESM+CJS、同形ランタイム条件、サブパスのプラグインエントリーを含む package.json の exports フィールドを作成する場合
• SDK の入力に変更があった場合にのみ再ビルドされ、下流のアプリが SDK のビルド出力（またはカスタム条件による生の src）を使用するように Turborepo を設定する場合
• publint --strict と attw --pack を prepublishOnly または CI に組み込む場合
• プレリリースチャンネルを管理する場合 — コミットごとの canary、次のメジャーバージョン向けの next、安定化のための beta／rc、安定版向けの latest — およびチャンネル間の移行（beta.N → rc.0 → 1.0.0 → 1.1.0-beta.0）
• GitHub Actions の changesets/action@v1 と npm provenance を使って changesets を設定する場合

---

実行ワークフロー

1つの TS SDK のビルドは、次の7つのフェーズで進みます。どれかを省略すると、後で問題が発生します。フェーズ間には実際に依存関係があります。

フェーズ 1 — ワークスペースとパッケージの骨組み

モノレポを構築し、空の SDK パッケージを作成します。

主な作業：

1. ワークスペースのルートに apps/ + packages/ + 必要に応じて tools/ を配置します
2. SDK を packages/<sdk-name>/（または packages/core/）に配置します
3. スコープ付きの名前（@<org>/<sdk-name>）を付けます
4. workspace:* プロトコルを使って、ワークスペース内の依存関係を接続します
5. 何よりも先に決めておきます。このパッケージは将来的に公開するため、そのことを念頭に境界と命名を設計します

my-repo/
├── pnpm-workspace.yaml
├── package.json          # root: only devDeps + workspace scripts
├── apps/
│   └── example-app/      # consumer of the SDK
└── packages/
    ├── sdk/              # ← the SDK
    └── shared-tsconfig/  # internal-only, never published

# pnpm-workspace.yaml
packages:
  - "apps/*"
  - "packages/*"

次に読むもの： references/workspace-and-layout.md — §2 レイアウト、§3 SDK の命名パターン、§4 内部パッケージの作成、§5 package.json のひな形、§7 複数リポジトリからモノレポへの移行。

フェーズ 2 — パブリック API

コードを書く前に、SDK の公開 API の形を決めます。

並行して検討する2つの要点：

A. モジュールの境界。 src/ ツリーは、api/（再エクスポートされ、契約の一部となるもの）と internal/（パッケージ外からインポートしてはいけないもの）に明確に分けます。package.json の exports フィールドは、最も手軽な強制手段です。ここに記載されていないものは、利用者がインポートできません。

packages/sdk/src/
├── index.ts          # barrel — re-exports from api/
├── api/
│   ├── client.ts
│   └── types.ts
└── internal/
    ├── transport.ts  # NOT exported
    └── state.ts      # NOT exported

B. 型の設計。 SDK の型は他の開発者が利用するものであり、内部実装を漏らさず、進化させられる必要があります。以下を使用します。

• 不透明な ID には ブランド型：type UserId = Brand<string, "UserId">
• 後から型パラメーターを追加しても互換性を損なわないよう、適切なデフォルトを備えた ジェネリッククライアント：createClient<Schema = DefaultSchema>(...)
• 結果型には 判別可能なユニオン：{ ok: true; value: T } | { ok: false; error: E } を持つ Result<T, E>
• オプションの組み合わせが重要な場合は、型安全な設定のための ビルダーパターン
• 宣言マージによってユーザーが型を拡張する可能性がある場合は、型エイリアスではなく インターフェース

次に読むもの：

• references/module-boundaries-and-plugins.md — §2 src/ の境界、§3 ランタイムのレイヤー構成、§4 プロバイダー／アダプター、§5 プラグインの拡張、§6 境界の強制、§7 パターンとアンチパターン
• references/type-design-for-public-api.md — §1 ブランド型、§2 ジェネリックな API、§3 条件型／マップ型、§4 型ガード、§5 ビルダー、§6 公開するユーティリティ型と内部用のユーティリティ型、§7 ライブラリ向け tsconfig、§8 API の進化

フェーズ 3 — ビルド設定

（a）ライブラリ出力に合わせた tsconfig.json と、（b）実際の dist/ を生成するバンドラーが必要です。

ライブラリ向けの tsconfig — 重要なフラグ：

// tsconfig.build.json — library build config
{
  "compilerOptions": {
    "target": "es2022",
    "module": "nodenext",
    "moduleResolution": "nodenext",
    "strict": true,
    "declaration": true,             // emit .d.ts
    "declarationMap": true,          // sourcemap from .d.ts → .ts
    "sourceMap": true,
    "verbatimModuleSyntax": true,    // TS 5.0+ — strict import elision
    "isolatedDeclarations": true,    // TS 5.5+ — explicit return types on public API
    "composite": true,               // enable project references
    "outDir": "./dist",
    "rootDir": "./src"
  },
  "include": ["src"]
}

2026 年のバンドラー選定： tsdown です。tRPC と Inngest は tsup から移行しました。tsup 自身の README にも、現在は 「このプロジェクトはもう積極的に保守されていません。代わりに tsdown の使用をご検討ください。」 と記載されています。

最小限の tsdown.config.ts：

import { defineConfig } from "tsdown";

export default defineConfig({
  entry: ["src/index.ts", "src/plugin/index.ts", "src/testing/index.ts"],
  format: ["esm", "cjs"],
  dts: true,
  sourcemap: true,
  treeshake: true,
  clean: true,
  outExtensions: ({ format }) => ({
    js: format === "esm" ? ".mjs" : ".cjs",
    dts: format === "esm" ? ".d.mts" : ".d.cts",
  }),
});

代替案：

• tsc-only / zshy — ランタイム依存関係がなく、ソースに忠実な公開を行う小規模 SDK 向け
• unbuild — すでに UnJS エコシステムを利用している場合のみ
• tsup — コミュニティでの認知度は高いものの、支持を失いつつあります。慣性による利用には適しています

次に読むもの：

• references/tsdown-bundling.md — §3 判定、§4 動作する設定、§6–§8 代替案、§11 選定判断ツリー
• references/type-design-for-public-api.md §7 — ライブラリ向け tsconfig の詳しい解説

フェーズ 4 — 配布形式（package.json の exports）

TS SDK のバグの多くはここで発生します。守るべき 5 つのルール：

1. 各 import / require 分岐では、types を必ず先頭に置きます
2. default は必ず最後に置きます
3. ESM と CJS の両方に対応する場合は、.d.mts と .d.cts を別々に用意する必要があります（TS 5.0 以降）
4. "./package.json": "./package.json" を必ず含めます（publint/attw による情報の参照が可能になります）
5. 両方を使う場合は、require より前に module を置きます

標準的なデュアル形式（@trpc/server の記述をそのまま掲載）：

{
  "exports": {
    "./package.json": "./package.json",
    ".": {
      "import": {
        "types": "./dist/index.d.mts",
        "default": "./dist/index.mjs"
      },
      "require": {
        "types": "./dist/index.d.cts",
        "default": "./dist/index.cjs"
      }
    }
  }
}

プラグインのエントリーポイントにはサブパスを追加し、ルートのバレルとは別にバージョン管理できるようにします：

{
  "exports": {
    ".":          { "import": { ... }, "require": { ... } },
    "./plugin":   { "import": { ... }, "require": { ... } },
    "./testing":  { "import": { ... }, "require": { ... } }
  }
}

同型 SDK（ブラウザー / ワーカー / RN / エッジ）では、ランタイム条件を import / require より前に置きます：

{
  ".": {
    "browser":      { "import": "./dist/browser.mjs" },
    "workerd":      { "import": "./dist/workerd.mjs" },
    "react-native": { "import": "./dist/rn.mjs" },
    "deno":         { "import": "./dist/deno.mjs" },
    "import":       { "types": "./dist/index.d.mts", "default": "./dist/index.mjs" },
    "require":      { "types": "./dist/index.d.cts", "default": "./dist/index.cjs" }
  }
}

次に読むもの： references/package-json-exports.md — §3 5 つのルール、§4 注釈付き tRPC デュアルパターン、§5 ESM のみのパターン、§6 サブパスプラグイン、§7 同型条件（Sanity クライアントのパターン）、§9 よくある間違いの修正例と理由。

フェーズ 5 — モノレポのパイプライン（Turborepo）

SDK を単独でビルドできたら、次のことができるようにワークスペースに組み込みます。

• SDK の出力に変更があった場合にのみ、アプリを再ビルドする（キャッシュ）
• ローカル開発中は SDK をウォッチモードで再ビルドしながら、アプリを再読み込みする
• CI では PR の影響を受けるパッケージのみをビルドする

最小限の turbo.json：

{
  "$schema": "https://turborepo.com/schema.json",
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "inputs": ["src/**", "tsconfig*.json", "tsdown.config.ts", "package.json"],
      "outputs": ["dist/**"]
    },
    "test":      { "dependsOn": ["^build"], "inputs": ["src/**", "test/**"] },
    "lint":      { "inputs": ["src/**"] },
    "typecheck": { "dependsOn": ["^build"], "inputs": ["src/**", "tsconfig*.json"] },
    "dev":       { "persistent": true, "cache": false }
  }
}

日常的に使う --filter パターン：

pnpm turbo run build --filter=@acme/sdk                   # SDK alone
pnpm turbo run dev   --filter=@acme/sdk... --filter=@acme/example-app
pnpm turbo run test  --filter=...@acme/sdk                # affected-by-SDK
pnpm turbo run lint  --filter=[HEAD^1]                    # affected since last commit

重要なルール： スクリプトはルートではなく、各パッケージの package.json に記述します。ルートでは turbo run X のみを実行します。

次に読むもの： references/turborepo-for-sdk.md — §2 最小限の turbo.json、§3 パッケージごとの設定とルート設定、§4 dependsOn、§5 キャッシュの入力 / 出力、§6 --filter パターン、§7 boundaries フィールド、§8 CI パターン、§9 ウォッチを使った開発モード。

フェーズ 6 — 検証

公開前に、静的チェック 2 つとランタイムチェック 1 つを必ず実行します。

# After pnpm build:
pnpm exec publint --strict                   # static lint of package.json
pnpm exec attw --pack .                      # simulate Node/Bun/Deno/bundler resolution

# Then pack + install in a sandbox dir
pnpm pack
cd /tmp/sandbox && npm init -y && npm install /path/to/your-pkg-1.0.0.tgz
node -e "console.log(require('@acme/sdk'))"                          # CJS reaches
node --input-type=module -e "import('@acme/sdk').then(console.log)"  # ESM reaches

3 つすべてを prepublishOnly に組み込みます。

{
  "scripts": {
    "prepublishOnly": "pnpm build && pnpm exec publint --strict && pnpm exec attw --pack ."
  }
}

publint と attw の両方が必要な理由： publint は package.json の形式を静的にチェックします。attw は各コンシューマーのランタイムで tarball がどのように解決されるかを実際にシミュレートします。attw で最もよく見られる失敗は偽装 ESMです。これは ESM を含む .js ファイルが require の配下で公開されている状態で、publint では検出できません。

次に読むもの： references/verification-and-publishing.md — §2 publint のルールとよくある失敗 3 つ、§3 attw の解決モード表と失敗モード 7 つ、§4 スモークテスト（tarball → 空のディレクトリ）。

フェーズ 7 — リリースライフサイクル

多くの SDK プロジェクトで負債が蓄積するのはここです。初日から正しく整えましょう。

Semver + プレリリース識別子：

0.x.y           # pre-1.0 — breaking changes allowed in minors
1.0.0-alpha.0   # internal feature spike
1.0.0-beta.0    # feature-complete, API may still shift
1.0.0-rc.0      # frozen, blocker-only fixes
1.0.0           # stable
1.0.1           # patch on stable
1.1.0-beta.0    # next minor's beta cycle while 1.0.x ships patches

npm dist-tag — プレリリースを latest に公開しないでください：

# Publish a beta under the `beta` tag (NOT `latest`)
npm publish --tag beta

# Recover from a mistaken latest:
npm dist-tag add @acme/[email protected] latest      # repoint latest to stable
npm dist-tag rm  @acme/sdk beta              # if no longer needed

慣例的なタグ：latest（安定版）、next（次期メジャーバージョンのプレリリース）、 beta、rc、canary（コミットごと）、alpha、experimental、nightly。

changesets のプレリリースモード — 基本となる切り替え手順：

# Cut beta line
pnpm changeset pre enter beta
pnpm changeset                  # write a changeset
pnpm changeset version          # bumps to 1.0.0-beta.0
pnpm changeset publish

# Feature-complete; move beta → rc
pnpm changeset pre exit
pnpm changeset pre enter rc
pnpm changeset version          # bumps to 1.0.0-rc.0
pnpm changeset publish

# RC stable; ship 1.0.0
pnpm changeset pre exit
pnpm changeset version          # bumps to 1.0.0
pnpm changeset publish

# Open next minor's beta line
pnpm changeset pre enter beta
pnpm changeset version          # bumps to 1.1.0-beta.0

npm provenance — 有効にします：

{
  "publishConfig": {
    "access": "public",
    "provenance": true
  }
}

GitHub Actions のリリースジョブで id-token: write 権限を設定してください。 npm はパッケージページに検証済みの証明を表示します。

次に読む内容： references/verification-and-publishing.md — §5 semver の復習、§6 dist-tag のルール、§7 ライフサイクル全体の状態図、§8 ケーススタディ （実際のバージョン系列を含む Next.js / vercel-ai / tRPC / Storybook / Stripe）、 §9 changesets のプレリリースフロー、§10 GitHub Actions のリリース ワークフロー、§11 provenance、§12 取り下げと非推奨化の違い、§13 戦略の判断ツリー。

---

クイックリファレンス

ファイル／フィールド早見表

ファイル	管理対象	クイックチェック
pnpm-workspace.yaml	パッケージのディレクトリ	apps/* + packages/*
ルートの package.json	ワークスペースの devDeps + turbo run の委譲先	ルートにパッケージレベルのビルドスクリプトがないこと
パッケージの package.json	name、version、type、exports、files、sideEffects、bin、scripts.prepublishOnly	publint --strict を実行
パッケージの tsconfig.json	エディター + tsc --noEmit	strict: true + declaration: true
tsconfig.build.json	ライブラリのビルド設定	高速な .d.ts が必要なら isolatedDeclarations: true
tsdown.config.ts	バンドル	format: ['esm', 'cjs'] + デュアル形式の outExtensions
turbo.json	タスクパイプライン	コンパイル順序に dependsOn: ['^build']
.changeset/config.json	リリースポリシー	commit: false、access: public

バンドラーの選び方

状況	選択肢
最新の TS SDK、ESM+CJS のデュアル形式、プラグインのサブパス	tsdown
ランタイム依存関係ゼロで、ソースに忠実なそのままの公開を希望	tsc のみ / zshy
tsup を使っている既存プロジェクトが問題なく動作している	tsup を継続使用し、tsdown への移行を計画
UnJS / Nuxt エコシステム	unbuild
バンドル分割 + 高度な rollup 設定が必要	rolldown を直接使用

モジュール形式の決定

状況	推奨
2026 年に新規作成する SDK のデフォルト	ESM + CJS のデュアル形式
Node 22 以上の安定した利用者基盤があるライブラリ	ESM のみも妥当
Node アプリ内でのみ使用する内部ライブラリ	ESM のみ
Jest、旧バージョンの Next.js、Lambda CJS で使用するライブラリ	デュアル形式が必須

リリースタグの早見表

タグ	意味	npm install pkg@? の解決先
latest	現在の安定版	npm install pkg
next	次期メジャーバージョンのプレリリース	npm install pkg@next
beta	機能が揃い、安定化中	npm install pkg@beta
rc	凍結済みで、ブロッカーのみ対応	npm install pkg@rc
canary	コミット／PR ごとのスナップショット	npm install pkg@canary
experimental	不安定な試験版	npm install pkg@experimental

よく入力するワンライナーのスニペット

# Add the SDK as a workspace-internal dep
pnpm add @acme/sdk@workspace:* --filter @acme/example-app

# Build SDK + everything that depends on it
pnpm turbo run build --filter=...@acme/sdk

# Pre-publish gate
pnpm build && pnpm exec publint --strict && pnpm exec attw --pack .

# Cut a snapshot release for a PR (vercel/ai pattern)
pnpm changeset version --snapshot pr-123
pnpm publish --tag pr-123 --no-git-checks

---

公開前チェックリスト

リリースごとに一度、以下を確認してください。項目を飛ばすと、SDK の不具合につながります。

ビルド成果物

• pnpm build により、.mjs と .cjs の両方（デュアル形式の場合）、または .mjs のみ（ESM のみの場合）を含む dist/ が生成される
• デュアル形式の場合は .d.mts と .d.cts が存在する。ESM のみの場合は .d.ts のみが存在する
• ソースマップが出力される（.mjs.map、.d.mts.map）
• dist/ のサイズが妥当である（du -sh dist/ で確認し、予期しない肥大化がないことを確認）

package.json

• name がスコープ付き（@org/name）である — 後からプライベートにする可能性がある場合は必須です
• version が公開する予定のバージョンと一致している
• type がデフォルトの形式と一致している（ESM がデフォルトなら"module"、CJS がデフォルトなら省略）
• exports に"./package.json": "./package.json"がある
• exports の各分岐で、types が先頭、default が末尾になっている
• files にdist（IDE の定義ジャンプ用にソースを同梱する場合はsrcも）を指定している
• sideEffects: falseを指定している（トップレベルに実際の副作用がある場合を除く）
• 初回のスコープ付き公開ではpublishConfig.access: "public"を指定している
• publishConfig.provenance: trueを指定している

検証

• publint --strictが成功する
• attw --pack .が成功する（または想定されるnode10の警告のみが出る）
• スモークテスト：パッケージ化＋/tmpへのインストールを行い、CJS、ESM、TS の各コンシューマーで解決できることを確認する

リリース

• 正しい dist-tag を選択している（安定版のみlatest）
• プレリリースの場合：versionの前にpnpm changeset pre enter <tag>を実行している
• 安定版の場合：以前プレモードだった場合はpnpm changeset pre exitを実行している
• CHANGELOG.mdに変更が反映されている
• Git タグがバージョンと一致している（例：v1.0.0-beta.3）
• Provenance attestation が npm パッケージページに表示されている

---

よくある間違い

間違い	問題点	修正方法
exportsの分岐内でtypesが先頭にない	TS が.jsを型ソースとして取得し、コンシューマー側でエラーが連鎖する	各import／require分岐の先頭にtypesを移動する（publint が警告します）
ESM と CJS の両方に単一の.d.tsを使う	TS が誤ったモジュールモードで.d.tsを解決する	.d.mts＋.d.ctsを出力する（TS 5.0+）。tsdown では自動的に行われます
exports に"./package.json": "./package.json"がない	publint／attw がパッケージを調査できない	必ず含めてください
プレリリースをlatestに公開する	npm install pkgを使うすべてのユーザーにベータ版が配布される	npm publish --tag betaを使い、npm dist-tag add pkg@stable latestで復旧します
安定版リリース前にpnpm changeset pre exitを忘れる	安定版のバージョンが1.0.0ではなく1.0.0-beta.Nになる	最終リリース前に必ずpre exitを実行してください
ルートのpackage.jsonに実際のビルドスクリプトを置く	Turborepo の並列処理とキャッシュが機能しなくなる	パッケージごとにスクリプトを設定し、ルートではturbo run経由で委譲するだけにします
コンシューマーからdist/internal/...を直接インポートする	コンシューマーが内部実装に依存し、リファクタリングで壊れる	内部実装をexportsに記載せず、ESLint のno-restricted-importsを使います
内部型を公開 API に漏らす	ユーザーが依存すべきでない型が見えてしまう	src/api/*.tsからのみ再エクスポートし、内部実装からexport *を使わないでください
副作用がないのにsideEffects: falseを指定しない	バンドラーがライブラリのツリーシェイキングを行えない	"sideEffects": falseを追加するか、実際に副作用があるファイルを列挙します
Provenance 用のid-token: write権限を忘れる	CI で Provenance attestation が失敗しても通知されない	リリースジョブにpermissions: { id-token: write, contents: read }を追加します
同じ Turbo タスクで watch と build を混在させる	キャッシュが絶えず無効になり、watch が安定しない	キャッシュ可能なbuildと、persistent: true, cache: falseを指定したdevを分けます
exportsでmoduleと無関係なランタイム条件を誤った順序で併記する	Edge ランタイムが誤ったファイルを選択する	ランタイム条件（browser、workerd）→ module → import → require → default
公開 API の型でenumを使う	コンシューマーを TS 専用にし、消去可能な構文を使えなくする	文字列リテラルのユニオンまたはas constオブジェクトを使います
SDK のルートからdefaultエクスポートを使う	ツリーシェイキングと相互運用性の仕組みを損なう	常に名前付きエクスポートを使います

---

参考ファイル

ファイル	使用する場面
references/workspace-and-layout.md	apps/ + packages/ + tools/ のセットアップ、SDK パッケージの命名、内部パッケージの作成、依存関係フィールド（dependencies / peerDependencies / devDependencies）の選択、マルチリポジトリからの移行
references/module-boundaries-and-plugins.md	src/ を api/ と internal/ に分割する、オーケストレーション層とアダプターとツールを設計する、ライフサイクルフックを備えたプラグイン拡張モデルを構築する、eslint-plugin-boundaries / dependency-cruiser / Turbo の boundaries で境界を強制する
references/type-design-for-public-api.md	ブランド型、ジェネリッククライアント、条件付き型とマップ型、型安全なビルダー、公開するユーティリティ型と内部にとどめるユーティリティ型、ライブラリ向け tsconfig フラグ（verbatimModuleSyntax、isolatedDeclarations、composite）、API の進化パターン
references/package-json-exports.md	exports フィールドの記述、個別の .d.mts / .d.cts を使った ESM + CJS の両対応、サブパスのプラグインエントリー、同型ランタイム条件（browser、workerd、react-native、deno、edge-light）、よくある exports の不具合の修正
references/tsdown-bundling.md	tsdown と tsup と tsc のみと unbuild の選択、最小限の tsdown.config.ts、サブパスの出力マッピング、副作用とツリーシェイキング、ウォッチモードと開発モード、バンドラー選択の判断フローチャート
references/turborepo-for-sdk.md	SDK モノレポ向けの turbo.json の記述、dependsOn: ['^build']、inputs / outputs のキャッシュ、SDK 開発向けの --filter パターン、boundaries フィールド、リモートキャッシュと変更のあった部分のみを対象とするビルドを使った CI、persistent: true による開発モード
references/verification-and-publishing.md	publint + attw のセットアップ、tarball のスモークテスト、semver + プレリリース識別子、npm dist-tag、beta → rc → stable → 次サイクルの完全な状態遷移、changesets のプレリリースモード、標準的な beta → rc 移行コマンドの一連の手順、スナップショット PR を含む GitHub Actions のリリースワークフロー、npm provenance、公開取り下げと非推奨化、リリース戦略の判断フローチャート

---

ソーススキル

このスキルは、oh-my-openclaw 内の 4 つのソーススキルを組み合わせて作成されました。

• agent-cli-architecture （architect-claw）— ワークスペースの構成、モジュール境界、ランタイムのレイヤリング、プラグイン拡張パターン。「エージェント CLI」という枠組みから、一般的な「SDK + サポート用 CLI」へと一般化しています。
• typescript-pro （frontend-claw）— ブランド型、ジェネリクス、条件付き型、型ガード、ユーティリティ型、tsconfig の詳細。ライブラリや SDK の作成者向けに再構成しています。
• turborepo （frontend-claw）— タスクパイプライン、キャッシュ、--filter、boundaries。SDK モノレポに関連する範囲に大幅に絞っています。
• monorepo-navigator （architect-claw）— pnpm ワークスペース、changesets、公開、移行。

さらに、package.json exports、2026 年における ESM / CJS の両対応、tsdown の動向、publint + attw、alpha → beta → rc → stable のライフサイクルについて独自に調査し、tRPC、vercel/ai、Inngest、Sanity client、Hono、Zustand、TanStack query-core の GitHub package.json にある例をそのまま掲載しています。