DeepSeek Harness: Publishing Plugins

Last updated: 2026-08-31

A well-written plugin running only on your own machine has limited value. Publishing to npm and GitHub lets other DSH users install and use it, integrating your plugin into the ecosystem. This lesson covers the full process from code to publication.

💡 Tip: The most important step before publishing isn't npm publish — it's writing a good README and compatibility declaration. Whether users can use your plugin depends on clear documentation.

📋 Prerequisites: Completed 15-define-tool.md, able to write complete tool plugins

1. What You'll Learn


Publish Options

2. npm Publishing Process

(1) Pre-Publish Checklist

Check Item Command/Method
Code compiles pnpm build
Tests pass pnpm test
package.json correct Check name/version/main
README exists File exists with complete content
.npmignore configured Exclude src/ and other dev files
npm logged in npm whoami

(2) ▶ Example 2

BASH
# Compile TypeScript
pnpm build

# Confirm output
ls dist/
# index.js  index.d.ts  ...

(3) ▶ Example 3

BASH
# First publish
npm publish --access public

# Publish after version update
npm version patch  # 1.0.0 → 1.0.1
npm publish

(4) ▶ Example 4

TEXT 📖 Display only
# .npmignore
src/
tests/
tsconfig.json
*.tsbuildinfo
.git/
.vscode/

Only publish compiled output, not source code.

(5) Post-Publish Verification

BASH
# Install in another project
pnpm add @dsh-plugin/my-tool

# Verify import
node -e "console.log(require('@dsh-plugin/my-tool'))"

3. package.json dsh Field

(1) dsh Field Structure

JSON
{
  "name": "@dsh-plugin/my-tool",
  "version": "1.0.0",
  "main": "dist/index.js",
  "types": "dist/index.d.ts",
  "dsh": {
    "name": "my-tool",
    "description": "A custom tool for DSH",
    "services": ["tools"],
    "inject": ["tools"],
    "capabilities": [],
    "compatibility": {
      "dsh": ">=0.5.0",
      "cordis": ">=1.0.0"
    },
    "permissions": [
      "fs.read",
      "network.outbound"
    ],
    "config": {
      "apiKey": {
        "type": "string",
        "required": true,
        "description": "API key for the service"
      }
    }
  }
}

(2) Field Descriptions

Field Type Description
name string Plugin identifier (matches export const name)
description string Plugin description
services string[] Provided services list
inject string[] Required services list
capabilities string[] Implemented capabilities list
compatibility object Compatibility requirements
permissions string[] Required permissions
config object Configuration item descriptions

(3) dsh Field Purpose


4. dsh-plugin GitHub topic

(1) Adding a topic

Add the dsh-plugin topic in GitHub repository settings:

TEXT 📖 Display only
Repository Settings → Topics → Add topic: dsh-plugin

(2) topic Purpose

Other users search for plugins via topic:

BASH
# GitHub CLI search
gh search repos --topic dsh-plugin --sort stars

# GitHub web search
https://github.com/topics/dsh-plugin
TEXT 📖 Display only
dsh-plugin        ← Required
deepseek-harness  ← Optional, increases discoverability
Tool type         ← e.g., database, search, devops

(4) Naming Conventions

Location Naming Example
npm package name @dsh-plugin/xxx @dsh-plugin/database
GitHub repo name dsh-plugin-xxx dsh-plugin-database
Plugin name xxx database

5. Version Management and semver

(1) semver Rules

Version format: MAJOR.MINOR.PATCH

Change Type Version Change Description
PATCH 1.0.0 → 1.0.1 Bug fix, backward compatible
MINOR 1.0.0 → 1.1.0 New feature, backward compatible
MAJOR 1.0.0 → 2.0.0 Breaking change

(2) Version Change Guide

TEXT 📖 Display only
When to bump PATCH:
  - Fix a tool bug
  - Fix a config validation issue
  - Documentation update

When to bump MINOR:
  - Add a new tool
  - Add a config option (with default)
  - Add a capability implementation
  - Add optional dependencies

When to bump MAJOR:
  - Remove a tool
  - Change tool parameter format
  - Remove a config option
  - Change inject list
  - Change Capability interface

(3) npm version Command

BASH
# Bump PATCH
npm version patch -m "fix: resolve timeout issue"

# Bump MINOR
npm version minor -m "feat: add batch query tool"

# Bump MAJOR
npm version major -m "breaking: change tool parameter format"

(4) Pre-release Versions

BASH
# Alpha version
npm version prealpha --preid alpha
# 1.0.0 → 1.1.0-alpha.0

# Beta version
npm version prebeta --preid beta
# 1.0.0 → 1.1.0-beta.0

# RC version
npm version prerelease --preid rc
# 1.1.0-beta.0 → 1.1.0-rc.0

6. Compatibility Declarations

(1) Declaration in package.json

JSON
{
  "dsh": {
    "compatibility": {
      "dsh": ">=0.5.0",
      "cordis": ">=1.0.0",
      "node": ">=18.0.0"
    }
  },
  "peerDependencies": {
    "@deepseek-ai/dsh": ">=0.5.0",
    "@deepseek-ai/cordis": ">=1.0.0"
  }
}

(2) Version Range Syntax

Syntax Meaning Matching Versions
>=0.5.0 Greater than or equal 0.5.0, 0.6.0, 1.0.0
^0.5.0 Compatible with 0.5.x 0.5.0 ~ 0.5.9
~0.5.0 Compatible with 0.5.0.x 0.5.0 ~ 0.5.0.9
0.5.x Any 0.5 patch 0.5.0 ~ 0.5.99

(3) Compatibility Check

BASH
# DSH built-in check
dsh plugin check @dsh-plugin/my-tool

# Output
✅ Compatible with dsh@0.5.0
✅ Compatible with cordis@1.0.0
⚠️ Requires Node.js >= 18.0.0 (current: 16.20.0)

(4) Handling Breaking Changes

When publishing a MAJOR version:

  1. Document all changes in CHANGELOG.md
  2. Provide a migration guide
  3. Maintain the old version for at least 6 months
  4. Mark "Breaking Changes" in README

7. Plugin Documentation Writing

(1) README Template

MARKDOWN
# @dsh-plugin/my-tool

> DSH plugin for [feature description]

## Installation

\```bash
dsh plugin add @dsh-plugin/my-tool
\```

## Configuration

\```yaml
plugins:
  '@dsh-plugin/my-tool':
    config:
      apiKey: sk-xxx
      maxRetries: 3
\```

## Provided Tools

| Tool | Description |
|:-----|:-----------|
| `my_tool` | Does something useful |

## Dependencies

- DSH >= 0.5.0
- Cordis >= 1.0.0

## Permissions

- fs.read
- network.outbound

### ▶ Example

\```text
👤 Alice: Analyze project with my_tool

🤖 Agent:
🔧 Using tool: my_tool
  → Result: ...
\```

## License

MIT

(2) Documentation Elements

Element Required Description
Install instructions One-line install command
Config instructions YAML config example
Tool list All provided tools
Dependency declaration DSH/Cordis version requirements
Permission declaration Required permissions and reasons
Usage example At least one complete example
API docs ⚠️ If providing a Service
Migration guide Only for MAJOR versions

(3) CHANGELOG Maintenance

MARKDOWN
# Changelog

## 1.1.0 (2026-08-20)

### Added
- batch_query tool for querying multiple paths
- Config option `maxDepth` for recursive analysis

### Fixed
- Timeout handling for large directories

## 1.0.0 (2026-08-01)

### Breaking
- Changed parameter format from `dir_path` to `path`

### Added
- Initial release with file_info tool

❓ FAQ

Q Must I use the @dsh-plugin/ prefix?
A Recommended but not required. The @dsh-plugin/ prefix makes searching and identification easier. Private plugins can use your own scope.
Q Can I publish only to GitHub without npm?
A Yes. Users install via github:user/repo. But npm installs are faster and more stable.
Q How to unpublish a released version?
A bash npm unpublish @dsh-plugin/my-tool@1.0.0 Only within 24 hours of publishing, and cannot unpublish versions with existing dependents.
Q Should I publish TypeScript source code?
A Recommended. Set "types": "dist/index.d.ts" in package.json and include .d.ts files. Exclude source via .npmignore.
Q How to test a plugin before publishing?
A bash # Local link testing cd dsh-plugin-my-tool npm link cd ../my-dsh-project npm link @dsh-plugin/my-tool # Verify dsh plugin list
Q What if I find a bug after publishing?
A Fix the bug → bump patch version → publish. Never modify an already-published version.

📖 Summary


📝 Exercises

1. ⭐ Basic: Add a complete package.json (with dsh field) and README.md for your previously written file_count tool plugin. Test locally with npm link.

2. ⭐⭐ Intermediate: Following semver conventions, add a new feature (new tool) to your plugin, bump MINOR version. Then fix a bug, bump PATCH version. Record each npm version command's output.

3. ⭐⭐⭐ Challenge: Publish your plugin to npm (can be --access public or a local registry). After publishing, install from another project and verify all functionality works. Write a CHANGELOG.md documenting the version history.

Web-Tutorial.com

Web-Tutorial Tech Team

A team of developers maintaining programming tutorials. Each tutorial is written and reviewed by developers with expertise in that field. We work to keep our content accurate and reliable — if you spot an issue, please let us know.

100%

🙏 帮我们做得更好

我们是刚上线的编程教程站,几个人的小团队,精力有限。页面虽经检查,难免还有疏漏——链接失效、排版错乱、内容有误、语言生硬……

如果您发现了,麻烦告诉我们,我们会在收到反馈后第一时间进行修复,再次感谢您的光临 🙏