DeepSeek Harness プラグイン公開:npm / GitHub / tarball

ローカルインストールはすでに動作しているので、プラグインを他の人に配布して使ってもらうことができます。

レジストリへの公開は必須ではありません。npm、tarball、Git の3つの方法があります。

3つの方法はビルド成果物に対する要件がまったく異なるため、選び間違えるとユーザー側で落とし穴にはまります。


3つの配布方法の比較

公式ドキュメントには3つの配布方法が記載されており、核心的な違いはプレビルド成果物を配布するかどうかにあります。

三种发布途径对比图

方法ユーザーのインストールコマンドインストールされるものビルド許可が必要か
npm 公開dsh plugin add your-packageプレビルド済みlib/コード不要
tarball 納品dsh plugin add ./hello-plugin-0.1.0.tgzpnpm pack生成されたパッケージ不要
Git インストールdsh plugin --profile demo add github:you/hello-pluginソースコード(ビルド成果物ではない)必要(pnpm ≥ 10)

npm と tarball はいずれもビルド権限を一切必要とせず、ユーザーに追加の許可を求めたくないシーンに適しています。

Git インストールは最も柔軟ですが、「ビルドスクリプト」という関門を越える必要があります。


git インストール:ビルドスクリプトという関門

Git インストールが取得するのはソースコードであり、ビルド成果物ではありません。

どの段階でもあなたの build スクリプトは実行されないため、TypeScript パッケージを受け取った時点でlib/出力がなく、読み込みに失敗します。

両側でそれぞれ1つずつ対応が必要です。

作成者側では、1つのprepareスクリプトを提供する必要があります。

pnpm は git インストール後にそれを実行し、ソースコードから公開エントリをビルドします。

それは自己完結型である必要があります:開発環境にしか存在しないコンテキスト(例えば、隣に monorepo チェックアウトがあること)を前提にしてはいけません。

turtle-uiは利用可能な例です。その prepare は専用の tsdown 設定を実行し、直接トランスパイルし、src/プロジェクト参照は使わず、型チェックも行いません。

実例

{
  "name": "dsh-hello-plugin",
  "scripts": {
    "prepare": "tsdown -c tsdown.publish.ts"
  }
}

上記の prepare スクリプトは自己完結型でなければなりません:直接トランスパイルし、src/隣の monorepo チェックアウトには依存しません。

ユーザー側では、ビルドを許可する必要があります。

pnpm ≥ 10 は明示的な許可を得るまで git 依存関係の prepare スクリプトの実行を拒否するため、最初の add は失敗します。

dsh は修正方法を示します:pnpm が出力した正確なパッケージキーをその profile のpnpm-workspace.yaml。

dsh plugin --profile demo add github:you/hello-plugin

最初の add は prepare が未承認のため失敗し、pnpm が正確なパッケージキーを出力します。

それを profile の pnpm-workspace.yaml にコピーします。次のようになります。

実例

# ファイルパス:$DSH_HOME/profiles/demo/pnpm-workspace.yaml
# pnpm が出力した正確なパッケージキーをここにコピーし、prepare の実行を許可します
allowBuilds
:
  dsh-hello-plugin
: true

その後、add を再実行します。

dsh plugin --profile demo add github:you/hello-plugin   # 第二次通过

この許可を正直に受け止めてください:それは、そのパッケージのコードがインストール時にあなたのマシン上で実行されることを許可し、しかも agent が実行するいかなるサンドボックスの中でもありません。

ソースコードが信頼できるパッケージにのみ許可を与え、commit をロックしてください(github:you/hello-plugin#<sha>)。これにより、後続のプッシュが実際に実行される内容をこっそり変更できなくなります。

commit をロックするインストールの書き方は次のとおりです。

dsh plugin --profile demo add github:you/hello-plugin#a1b2c3d   # 锁定到具体 commit

npm と tarball:ビルド許可が不要

ユーザーに許可をさせたくない場合は、ビルド成果物を配布するように変更します。

以下の2つの形式はどちらもビルド権限を一切必要としません。

1つ目は、npm に公開します。

にpnpm publish時にビルドしておき、lib/ユーザーがdsh plugin add your-packageインストールするのはプレビルド済みコードです。

# 作者侧:先构建再发布
pnpm build
pnpm publish

# 用户侧:安装的是预构建代码,无需授权
dsh plugin add your-package

2つ目は、tarball を納品します。

用 pnpm packパッケージ化し、ユーザーが実行しますdsh plugin add ./hello-plugin-0.1.0.tgz。

# 作者侧:打出 tgz
pnpm pack

# 用户侧:直接安装 tarball 文件
dsh plugin add ./hello-plugin-0.1.0.tgz

選択のアドバイス:ソースコードが信頼でき、ビルドプロセスを省きたい場合は、git インストールを使用して commit をロックします。一般ユーザー向けの場合は、npm 公開または tarball 納品を優先し、ユーザーが許可なしで直接インストールできるようにします。


まとめと自己テスト

3つの配布方法は、プレビルド成果物を配布するかどうかで区別されます:npm と tarball はビルド許可が不要で、Git インストールはソースコードを取得するため、作者の自己完結型 prepare スクリプトとユーザーの allowBuilds 許可が必要です。

自己テスト問題:

  1. なぜ git インストールは TypeScript パッケージで失敗するのですか?作者は何をする必要がありますか?
  2. pnpm ≥ 10 のユーザーが最初の add に失敗した場合、dsh はどのように修正するよう提案しますか?
  3. なぜ commit sha のロックを推奨するのですか?
その他の拡張