Introduction¶

Manually publishing a DSH plugin usually involves repeating over a dozen steps: creating a new repository, adding README badges and installation instructions, selecting a license, writing .gitignore, filling repository/homepage/keywords into package.json, git init, configuring identity, committing, switching branches, creating remote, pushing, tagging, creating a Release, and finally adding topics back. Publishing to npm requires another set of procedures: confirming the version number isn’t occupied, running npm publish, checking the registry, and verifying the README is normal. Publishing a new version is even more troublesome—the version number needs to be bumped, and both GitHub and npm need to be redone.

The wodaimnd/dsh-github-publisher introduced below is designed to address this pain point. It is a DSH Web plugin that provides a “Multi-Platform Publish Console” in the left sidebar, consolidating all the above steps into one page: enter publishing details once, check target platforms, click one button to run them sequentially, and see progress grouped by platform, with the option to cancel.

What is this¶

The plugin is named dsh-github-publisher, maintained by wodaimnd, categorized as “Workflow” in the community directory, and currently has 1 star. Positioning in one sentence: publish local DSH plugins to multiple platforms (GitHub / npm) in one go.

It does not replace the platforms themselves but relies on the local git, Node’s built-in npm, and each platform’s REST API. The plugin form is a Web plugin with no build steps, adding a “Multi-Platform Publish Console” entry in the left sidebar, with the interface theme following the host (light/dark auto-switching).

Currently, the version in package.json is 0.3.4, and the license is MIT.

Core Features¶

Plugin Discovery. Scans profile link:/file: dependencies, registered workspaces, current directory, and custom scan directories, identifies packages with dsh.bundle / dsh.client, and displays version, description, README/LICENSE status, git status, and published platforms.

One set of publishing details + platform selection matrix. Fill name / version / description / descriptionZh / topics / license / README / releaseNotes once; each platform is a row of checkboxes with status badges (disabled / credentials not set / token masked). After checking npm, expand its own access, dist-tag, 2FA OTP; when GitHub is unchecked, the repository field is read-only and doesn’t participate in validation, meaning publishing to npm only doesn’t require a GitHub account.

Platform configuration page. Configure credentials and defaults for each platform. The GitHub side shows account status, toggle switch, verify credentials (Enterprise address in settings popup); the npm side shows Registry, Access Token (validates against registry on save, masked display and clear), access, dist-tag, provenance toggle, and verified account.

One button to publish to all platforms. Button text changes with selection (e.g., “Publish to GitHub + npm registry”). Task steps are executed grouped by platform: GitHub is verify account → create/reuse repo → topics → commit → push → tag + Release; npm is verify credentials → version guard → npm publish → check registry. Failure of a single platform does not interrupt others, and results are shown with independent links and failure reasons for each platform.

npm version guard. Before publishing, compare with the latest on the registry; if the version is the same or lower, it is directly flagged as a blocker and prompts to bump first, rather than waiting until you reach publish to get EPUBLISHCONFLICT.

Version sync matrix. Plugin × Platform × Local Version × Remote Version × Status (synced / behind / unpublished / local update / unknown). GitHub reads the latest Release tag, npm reads the registry’s latest. Behind rows can be “Publish to behind platform” with one click, or “Only bump version” first to do patch/minor/major bump.

AI completion of publishing info. The “AI Complete Info” in the top right reads package.json / README / file list using the configured DeepSeek model in DSH, generates English description, Chinese description, topics, and Release notes, which can be manually edited after filling the form. This step only uses DSH’s model quota, involves no platforms, and does not trigger automatic publishing.

Auto-completion of repository files (preview then write). README.md generates a bilingual complete template; LICENSE supports MIT / Apache-2.0 / BSD-3-Clause / GPL-3.0 standard full text and automatically fills year and author; .gitignore uses Node/DSH plugin common templates; package.json only fills missing repository / homepage / bugs / keywords / license / author / description, without overwriting manually written fields.

Preflight and Dry Run. Preflight covers platform selection, git/npm CLI availability, token validity, package name and remote version occupation, whether repository exists, commit identity, files to be written, workspace dirty state, remote rewrite, etc. Blockers are highlighted in red and located. After checking “Dry Run”, only local preparation and commits are done, no repo creation, no push, no Release creation, npm uses --dry-run, and the entire flow can be run without any credentials.

Data and Security. Settings, platform credentials, draft forms for each plugin, and the last 50 publish records are saved in ~/.dsh/github-publisher/ (inherited historical directory); tokens are only stored in local config.json (0600), responses and logs are only masked. GitHub push uses temporary GIT_ASKPASS (0700, deleted after use), npm token is only passed via subprocess environment variables, not in argv, and not written to .npmrc. If the local machine already has GITHUB_TOKEN/GH_TOKEN, gh auth token, or github.com credentials in git credential, they will be automatically detected and used during publishing; npm also supports NPM_TOKEN as a fallback (only in memory, not on disk).

Nested plugin security. If the plugin directory is inside a parent git repository (common in monorepos/workspaces), the publish console will establish an independent git repository inside the plugin directory without affecting the parent repository; preflight will explicitly warn that the parent repository will see these file changes.

Agent Tools and HTTP API. The same set of operations is also exposed as an Agent tool github_publisher (state / scan / preflight / publish / job / cancel / settings / token / history / suggest), sharing the same Publisher service with the UI, and form.platforms determines which platforms to publish to this time. The external HTTP API is /dsh-github-publisher/api/*, adding interfaces like platforms, platforms/verify, platforms/npm-token, version/bump, sync/plan, etc. See CONTRACT.md in the repository for the full interface.

Installation and Enablement¶

The plugin is installed via a local bundle link (i.e., ready to use, no remote package name fetching). Run in DSH:

plugin_manager action=install_bundle target=/absolute/path/to/dsh-github-publisher

Change target to the absolute path of your plugin directory on your local machine. After installation, refresh the DSH Web page (or restart Desktop), and the “Multi-Platform Publish Console” icon will appear in the left sidebar.

There are two ways to uninstall, choose as needed:

plugin_manager action=remove_bundle

Or via the interface: Settings → Plugins → GitHub Publisher → Remove.

Typical Usage¶

Using a local plugin as an example, walk through the process from configuration to publishing.

1. First-time configuration: Bind GitHub token. Open the publish console, the “Getting Started Guide” card at the top has all necessary links and buttons arranged. In the first step, click “Request Classic PAT” or “Request Fine-grained PAT”:

• Classic token: Check repo; add workflow if you need to write workflow files.
• Fine-grained token: Repository permissions Contents: Read and write, Administration: Read and write, Metadata: Read-only.

The authorization page will automatically include the scope. After creation, copy the token, paste it into the input box, and click “Save and Verify”. After success, it displays @your-username, masked token, and source. If you don’t want to fill it manually, you can click “Auto Detect”, which sequentially tries GITHUB_TOKEN / GH_TOKEN environment variables, gh auth token, and github.com credentials saved in git credential; the detected token is by default only stored in memory and only saved to disk when “Save” is clicked.

2. Bind npm token (optional). In the third step of the wizard, click “Request npm Token”, it is recommended to choose the Automation type. Go back to the npm card in the “Platform Configuration” tab, check “Enable this platform”, fill in Registry (default https://registry.npmjs.org) and Access Token, and click “Save and Verify”. When publishing only to npm, this step is necessary, just don’t check the GitHub row.

When using a self-hosted registry (Verdaccio / Internal Nexus), there is no /settings/tokens web route, so the plugin uses a different route: first click “Copy npm login command” and execute it in the terminal (e.g., npm login --registry=http://127.0.0.1:4873), then click “Copy .npmrc key name” to get //127.0.0.1:4873/:_authToken=, copy the value after the equals sign from ~/.npmrc and paste it back to verify.

3. Select plugin, complete info, preflight. Select the target plugin in the left plugin list. If necessary, first “Rescan” or add scan directories in settings. The publishing info card has automatically pulled in repository name/intro/topics/license, etc., fill in whatever is missing; you can also click “AI Complete Info” in the top right to let the DeepSeek model in DSH generate description, Chinese intro, topics, and Release notes. If npm is checked, that row expands access / dist-tag / 2FA OTP. For the first time, it is recommended to check “Dry Run” first.

4. Publish. In “Publish Options”, check as needed to generate README/LICENSE/.gitignore, improve package.json, create Release, commit message template, author identity, and then:

# Equivalent process via UI: Precheck → Publish to selected platforms

Click “Preflight” to see the targets and blockers for both platforms, as well as files to be written (README can be previewed). After confirmation, click the button and observe the progress and logs grouped by platform. After completion, the result card provides independent links for repository, Release, commit, and npm registry, along with failure reasons.

When publishing a new version, you don’t need to redo everything: open the “Version Sync” tab, see which platforms are behind, directly click “Publish to behind platforms”, or first “Only bump version” to do patch/minor/major bump.

Applicable Scenarios and Notes¶

Suitable for developers who maintain DSH plugins themselves and need to synchronize publishing to both GitHub and npm channels, especially those already managing plugins in monorepos/workspaces who are tired of manual synchronization on both sides.

Two points to note:

• The plugin runs with the current DSH process permissions; check its source code and license (MIT) before installing. The issued token permissions are real; it is recommended to only use the plugin locally and apply for the minimum scope; although the token is only saved to config.json with 0600 permissions and only masked in responses/logs, the authorization page itself is still the official GitHub/npm page. GitHub and npm authentication are independent of each other; the DeepSeek token is only used for AI completion and cannot be used as GitHub/npm credentials, nor can they be swapped.
• It handles the publishing process, it does not decide the version number for you. npm does not accept republishing with the same name version, remember to bump before publishing a new version.

Conclusion¶

This plugin solves a specific and repetitive problem: converging the multi-platform publishing of local DSH plugins from over a dozen manual steps into one fill, one preflight, and one button. It does not introduce new publishing standards, but arranges the respective processes of GitHub and npm into the same interface and uses the version sync matrix to cover subsequent releases.

Directory page: https://www.skillhub.cn/plugins/wodaimnd/dsh-github-publisher
Repository: https://github.com/wodaimnd/dsh-github-publisher