CH 23 · 公開と配布
本章の目標
PART 04 を一通り進めてきて、プラグインのインストールも書き方もマスターしました――でもそれはまだあなたのワークスペースのフォルダの中に置いているだけです。他の人はどうやって手に入れるのでしょうか？ この章ではそれを「他人が一コマンドでインストールできる」配布物へと変換します。まずは他人があなたのプラグインをインストールする仕組み（bundle パッケージ）を説明し、次に 3 つの配布方法を紹介し、最後に公開前に自分で一度インストールして動作確認し、問題ないことを確認してから公開します。
まず整理：他人はどうやってあなたのプラグインをインストールするのか
dsh には内蔵のプラグインマーケットがありません。公式のインストールは一律 dsh plugin --profile <名前> add <ソース> で行います。ソースは 4 種類：npm パッケージ名 / ローカルディレクトリ / tarball / GitHub Release（CH 17 で体系的に解説しました）。つまりあなたがやるべきことは、自分が書いたプラグインをこの 4 つのソースのいずれかに変換することです。
そして「他人が add できるプラグイン」は、dsh では正式名称があります――**bundle（パッケージ）**です。2 つの概念を混同しないでください。
- bundle はあなたが作成し配布するものです。その package.json は
dsh.bundleを宣言し、「このパッケージは何を提供するか」――プラグイン行を挿入または上書きする patch ファイル――に答えます。 - profile はユーザーが
dsh --profile <名前>で起動するものです。その package.json はdsh.profileを宣言し、「どの bundle がどの順序でこの構成を構成するか」に答えます。
両者を兼ねるものはありません。あなたが bundle を配布し、ユーザーがそれを profile でインストールして起動します。
公開可能なプラグインとはどんなものか
完成したプラグインディレクトリの中で、最も重要な 3 つの要素:
your-plugin/
├── package.json # dsh.bundle を宣言（UI 付きなら dsh.client も宣言）
├── cordis.patch.yml # インストール時に適用される patch レイヤ
└── lib/ # ビルド成果物――他人が実際にインストールするのはこれpackage.json の以下のフィールドは、どれ一つとして曖昧にできません:
| フィールド | 説明 |
|---|---|
name | パッケージ名、プラグインと一致し、読みやすくする |
version | セマンティックバージョン、メジャー.マイナー.パッチ、初期値は 0.0.1 |
description | プラグインの機能を 1 行で説明、インストール一覧に表示される |
type | module（ESM） |
main | ビルド成果物を指す、例: lib/index.js |
files | 配布するものだけをパッケージング: lib、cordis.patch.yml、LICENSE など。lib を漏らすと、他人インストール後に必ずロード失敗する |
keywords | 検索キーワード、["deepseek","harness","dsh","dsh-plugin",...]――dsh-plugin は見つけてもらいやすくするための必須 |
license | オープンソースは宣言必須、例: MIT |
dsh.bundle | {"patch":"./cordis.patch.yml"}――これはパッケージであることを宣言し、インストール時に自動マウントされる |
dsh.client | UI 付きプラグインは client 注入を宣言（CH 22 で解説した仕組み） |
3 つの配布方法
軽い方から重い方へ。1 つ目は純粋にローカルで自己テストするもので、アカウントは一切不要です。後の 2 つはアカウントが必要です――GitHub は GitHub アカウント、npm は npm アカウント。
方法 1: ローカルディレクトリ / tarball――公開前の自己テスト
- ローカルディレクトリ:
dsh plugin --profile demo add ./your-plugin、pnpm がそのディレクトリを直接リンク、開発中のクイック試行に適している。 - tarball: プラグインディレクトリで
pnpm packを実行して.tgzを作成し、dsh plugin --profile demo add ./your-plugin-0.0.1.tgz。
公開する前に、必ず tarball で自分で一度インストールして試すこと――tarball はあなたが配布するものとまったく同じです。インストールでき、動作してこそ、初めて公開を検討できます。自己テスト 3 ステップ:
# プラグインディレクトリでパッケージング
pnpm pack
# クリーンな一時 profile にインストール
dsh plugin --profile test add ./your-plugin-0.0.1.tgz
# 構成ツリーに入ったか確認
dsh --profile test --dump-config--dump-config の出力にあなたのプラグインのレイヤが見えれば、パッケージのロードは成功しています。次に dsh --profile test で起動し、プラグインの機能が正常に動作するか確認、すべて正常なら公開します。
2 つの詳細を覚えておいてください:
- bundle メンバー変更後は profile を再起動しないと有効にならない――実行中の profile は起動時点の bundle セットを保持しています（CH 17 の境界）、インストール後に再起動してからテストする。
- ロード順序: profile の bundles リスト → profile 自身の cordis.patch.yml →
$DSH_HOME/cordis.patch.yml→--patchoverlay、後に適用された行が優先。あなたのプラグインは最初のレイヤに属します。
dsh に直接やってもらうこともできます: 以下を dsh に送れば、dsh は自分でドキュメントを読み、パッケージングし、一時 profile をインストールし、検証します。あなたは確認するだけ。
現在のワークスペースにあるプラグインを、配布可能な形式にパッケージングして、公開前の自己テストを実施してください。まず dsh 公式ドキュメントを読んで、プラグインのパッケージングとインストール方法（bundle パッケージ、dsh plugin add の 4 つのソース）を理解し、公式仕様に従ってください。プラグインを tarball にパッケージングし、package.json のメタデータ（バージョン、description、files、keywords、license）が揃っているか確認します。一時 profile にインストールして、ロードでき機能が正常か検証してください。最後に検証結果とパッケージ成果物のパスを教えて、npm に公開するためにまだ何が必要か説明してください。方法 2: GitHub――他人は 1 つの URL でインストール
コミュニティで最も多いのはこの方式です: ビルド成果物を作成し、GitHub Release にアップロードし、他人は単一の URL でインストール。CH 12 でインストールした DSH Skill & MCP Panel もこの方式で配布されていました。
手順は 3 ステップ:
- パッケージング: プラグインディレクトリで
pnpm packを実行し、your-plugin-0.0.1.tgzを取得。 - アップロード: リポジトリを GitHub にプッシュし、リポジトリページで Release を作成（バージョン番号
v0.0.1を記述）、.tgzをアップロード。 - インストール用 URL を伝える: 他人は次のアドレスでインストール:
dsh plugin --profile web add https://github.com/your-username/repo-name/releases/download/v0.0.1/your-plugin-0.0.1.tgzインストールされるのはビルド成果物であり、allowBuilds 認可は不要、npm からのインストールと同じように簡単です。「常に最新版を指す」固定アドレスにしたい場合は、download/v0.0.1/... を releases/latest/download/your-plugin.tgz に置き換えてください（ファイル名にバージョン番号を含めない）。
注意: この方式を取るプラグインでは、lib/ は通常 git に含めません――リポジトリにはソースコードのみを置き、公開前にローカルでビルドし、pnpm pack で tarball にしてから Release にアップロードします。
上級: GitHub Actions による自動ビルド・公開
手動でのパッケージング、Release の作成、ファイルのアップロードを 1 回やるだけなら良いですが、バージョンが増えてくると面倒です。GitHub Actions に任せましょう: v0.0.1 のようなタグをプッシュすると、Actions が自動でビルド → pnpm pack → Release 作成 → tarball のアップロードを実行します。それ以降は新しいバージョンのタグをプッシュするだけで、他はすべて自動です。
典型的な workflow はリポジトリの .github/workflows/release.yml に配置: トリガーは push: tags: ['v*']、手順はチェックアウト、Node インストール、pnpm install、pnpm build、pnpm pack、次に softprops/action-gh-release で Release を作成し、生成された .tgz を添付ファイルとしてアップロード、という順。一度設定すれば、バージョンごとに手動でファイルをアップロードする必要はなくなります。
dsh に直接公開してもらうこともできます
パッケージング、リポジトリのプッシュ、Release の作成――これらの繰り返し作業は、dsh に任せましょう。Web UI の入力欄に以下を送信:
現在のワークスペースにあるプラグインを GitHub に公開し、v0.0.1 バージョンをリリースしてください。dsh 公式仕様に従い、GitHub Actions で自動ビルド・公開を行い、最後に他人がどのアドレスでインストールできるか教えてください。dsh は自分でドキュメントを読み、自分でコマンドを実行し、git と Release を自分で処理します。リポジトリのプッシュや Release の作成など境界を越える操作で権限ポリシーに従って確認し、最後にインストール用アドレスが正しいか検証するだけです。
方法 3: npm に公開――他人はパッケージ名を書くだけ
プラグインを npm に公開すれば、他人のインストールが最もシンプルになります: dsh plugin --profile web add your-plugin。
手順は 4 ステップ:
- npm 登録とログイン: npm 公式サイトでアカウント登録（無料）、次に
npm login（ユーザー名、パスワード、メールを聞かれます）。 - ビルド:
lib/がビルド成果物であることを確認。ソースコード型のプラグインはpnpm buildしてから公開する――npm は事前ビルドされたコードをインストールするので、ビルドせずに公開すると、他人の手元には空っぽのパッケージが届きます。 - 公開: プラグインディレクトリで
pnpm publishを実行。 - 検証: クリーンな profile に切り替え、
dsh plugin --profile test add your-plugin、インストールと実行ができるか確認。
公開後: dsh-plugin トピックを付ける
いずれの方法でも、GitHub リポジトリの Topics に dsh-plugin を追加してください――公式チームが明示的に推奨しており、他の人があなたのプラグインを見つけやすくなります。npm パッケージの keywords にも dsh-plugin を含めることを忘れずに、二重に効きます。
よくある落とし穴
| 問題 | 何が起きているか | 対処方法 |
|---|---|---|
| インストールしたけど効果がない | bundle メンバー変更後に再起動していない | インストール後に profile を再起動してからテスト |
| 他人がインストール後にロード失敗 | files から lib/ が漏れており、ソースのみ配布 | files にビルド成果物ディレクトリを追加して再パッケージ |
| バージョン番号の重複 | 同じバージョンで publish は npm に永久拒否される | 別のバージョンに変更してから公開 |
| パッケージ名が使用済み | npm に同じ名前のパッケージが既に存在する | 競合しないパッケージ名を選ぶ |
| インストールしたが有効化されない | パッケージが dsh.bundle を宣言していない | "dsh":{"bundle":{...}} を追加、そうでなければ通常の依存としてのみ存在しマウントされない |
この章で学んだこと
以下の項目を完了できれば合格です:
- [ ] bundle は「あなたが配布するもの」、profile は「ユーザーが起動するもの」であり、両者の manifest が異なることを理解している
- [ ] 公開可能なプラグインの正しい package.json を書ける: name / version / files / keywords / license / dsh.bundle、UI 付きなら dsh.client も
- [ ] 3 つの配布方法それぞれの適用シーンを理解している: ローカル/tarball 自己テスト、GitHub Release tarball（主流のワンクリックインストール、Actions 自動公開対応）、npm 公開
- [ ] 公開前の自己テストができる:
pnpm pack→ 一時 profileadd→--dump-configで確認 → 再起動で検証 - [ ] dsh にパッケージング、自己テスト、GitHub への公開をやってもらえることを知っており、手動で 1 ステップずつやる必要はない
- [ ] 公開後、GitHub リポジトリに
dsh-pluginトピックを付け、npm パッケージの keywords にdsh-pluginを含めることを知っている - [ ] よくある落とし穴を回避できる:
filesからlib/が漏れる、bundle 変更後に再起動しない、パッケージがdsh.bundleを宣言していない