DeepSeek Harness Plugin veröffentlichen: npm / GitHub / Tarball
Die lokale Installation funktioniert bereits; wir können das Plugin an andere zur Nutzung weitergeben.
Eine Veröffentlichung in einer Registry ist nicht erforderlich; es gibt drei Ansätze: npm, tarball und Git.
Die drei haben völlig unterschiedliche Anforderungen an Build-Artefakte; eine falsche Wahl führt zu Fallstricken auf Nutzerseite.
Vergleich der drei Verteilungsmethoden
Die offizielle Dokumentation nennt drei Verteilungsmethoden, wobei der Kernunterschied darin besteht, ob vorgefertigte Artefakte verteilt werden.
| Methode | Installationsbefehl für Benutzer | Was installiert wird | Ob eine Build-Genehmigung erforderlich ist |
|---|---|---|---|
| npm publish | dsh plugin add your-package | Vorgefertigtlib/Code | Nicht erforderlich |
| Tarball-Lieferung | dsh plugin add ./hello-plugin-0.1.0.tgz | pnpm packGebautes Paket | Nicht erforderlich |
| Git-Installation | dsh plugin --profile demo add github:you/hello-plugin | Quellcode (nicht Build-Ausgabe) | Erfordert (pnpm ≥ 10) |
Weder npm noch Tarball erfordert Build-Berechtigungen, was sie für Szenarien geeignet macht, in denen Sie nicht möchten, dass Benutzer eine zusätzliche Autorisierung vornehmen.
Die Git-Installation ist am flexibelsten, aber sie muss die Hürde des "Build-Skripts" überwinden.
Git-Installation: die Build-Skript-Hürde
Die Git-Installation zieht Quellcode, keine Build-Artefakte.
Kein Schritt führt Ihr Build-Skript aus, wenn also ein TypeScript-Paket ankommt, gibt es keinelib/Ausgabe, und das Laden wird fehlschlagen.
Beide Seiten müssen jeweils eine Sache tun.
Auf der Seite des Autors müssen Sie einprepareSkript bereitstellen.
pnpm führt es nach einer git-Installation aus und erstellt den Veröffentlichungs-Einstiegspunkt aus dem Quellcode.
Es muss eigenständig sein: Es darf keinen Kontext voraussetzen, der nur in der Entwicklungsumgebung existiert, wie etwa ein benachbartes Monorepo-Checkout.
turtle-uiDies ist ein brauchbares Beispiel: Sein prepare führt eine dedizierte tsdown-Konfiguration aus, die direkt transpiliertsrc/, ohne Projektreferenzen und ohne Typprüfung.
Beispiel
"name": "dsh-hello-plugin",
"scripts": {
"prepare": "tsdown -c tsdown.publish.ts"
}
}
Das obige prepare-Skript muss eigenständig sein: direkt transpilierensrc/, ohne vom benachbarten Monorepo-Checkout abzuhängen.
Auf der Nutzerseite müssen Sie den Build genehmigen.
pnpm ≥ 10 weigert sich, prepare-Skripte für git-Abhängigkeiten auszuführen, bis sie ausdrücklich erlaubt sind, daher wird das erste add fehlschlagen.
dsh wird die Lösung aufzeigen: Kopiere den exakten Paketschlüssel, den pnpm ausgegeben hat, in diepnpm-workspace.yaml dieses Profils.。
dsh plugin --profile demo add github:you/hello-plugin
Das erste add wird fehlschlagen, weil prepare nicht autorisiert ist, und pnpm wird den exakten Paketschlüssel ausgeben.
Kopieren Sie es in die pnpm-workspace.yaml des Profils, wie folgt.
Beispiel
# Kopieren Sie den exakten Paketschlüssel, den pnpm ausgibt, damit es prepare ausführen kann
allowBuilds:
dsh-hello-plugin: true
Führen Sie dann add erneut aus.
dsh plugin --profile demo add github:you/hello-plugin # 第二次通过
Seien Sie ehrlich bei dieser Genehmigung: Sie erlaubt dem Code des Pakets, während der Installation auf Ihrem Rechner ausgeführt zu werden, nicht in einer Sandbox, die der Agent ausführt.
Autorisieren Sie nur Pakete, deren Quellcode vertrauenswürdig ist, und fixieren Sie den Commit (
github:you/hello-plugin#<sha>), damit zukünftige Push-Vorgänge nicht stillschweigend ändern können, was tatsächlich ausgeführt wird.
Die Installationssyntax zum Fixieren eines Commits lautet wie folgt.
dsh plugin --profile demo add github:you/hello-plugin#a1b2c3d # 锁定到具体 commit
npm und Tarball: Autorisierung ohne Build
Wenn Sie nicht möchten, dass Benutzer die Autorisierung vornehmen, verteilen Sie stattdessen Build-Artefakte.
Keine der folgenden beiden Formen erfordert Build-Berechtigungen.
Der erste Ansatz: Veröffentlichen auf npm.
Beipnpm publishwird zur Veröffentlichungszeit gebautlib/, der Benutzerdsh plugin add your-packageWas installiert wird, ist vorgefertigter Code.
# 作者侧：先构建再发布 pnpm build pnpm publish # 用户侧：安装的是预构建代码，无需授权 dsh plugin add your-package
Die zweite Option: Bereitstellung des Tarballs.
verwendenpnpm packPaket, Benutzer führt ausdsh plugin add ./hello-plugin-0.1.0.tgz。
# 作者侧：打出 tgz pnpm pack # 用户侧：直接安装 tarball 文件 dsh plugin add ./hello-plugin-0.1.0.tgz
Empfehlungen: Wenn der Quellcode vertrauenswürdig ist und Sie den Build-Prozess überspringen möchten, verwenden Sie die Git-Installation und fixieren Sie den Commit; für normale Benutzer bevorzugen Sie die Veröffentlichung auf npm oder die Bereitstellung eines Tarballs, sodass Benutzer direkt ohne jegliche Autorisierung installieren können.
Zusammenfassung und Selbsttest
Die drei Verteilungsmethoden unterscheiden sich darin, ob vorgefertigte Artefakte verteilt werden: npm und Tarball erfordern keine Build-Autorisierung; die Git-Installation zieht den Quellcode und erfordert das eigenständige prepare-Skript des Autors und die allowBuilds-Autorisierung des Benutzers.
Selbsttestfragen:
- Warum schlägt die Git-Installation bei TypeScript-Paketen fehl? Was muss der Autor tun?
- Wenn Benutzer von pnpm ≥ 10 beim ersten add fehlschlagen, wie schlägt dsh vor, das zu beheben?
- Warum wird empfohlen, den Commit-sha zu fixieren?