Introduction¶

When releasing projects or plugins in DSH, several things are often manually checked before the release: whether package.json has been modified, whether the lock file is synced; whether the CHANGELOG is still from the previous version; whether the download page or site page displays the old version number; and whether the pipeline still has RELEASE_VERSION=0.9.0 hardcoded. Missing any of these, users will discover the version mismatch only after installation, or the store page will display last month’s number.

Below is an introduction to feely0208/dsh-release-guard (npm package name @deepwhale-cn/dsh-release-guard). It turns “can I release now, what is missing” into a command, giving a conclusion and evidence for each check. The DSH Community directory is an independent site with no official affiliation with DeepSeek / Fenxi.

What is it¶

One-sentence positioning: A pre-release consistency checking tool. It does not judge code quality, nor does it run tests or build, only judging whether release metadata and files are self-consistent.

The repository is feely0208/dsh-release-guard, package name @deepwhale-cn/dsh-release-guard. The README’s package.json shows current version 0.1.0, license MIT, requires dsh >=0.1.0-rc.6 <0.3.0 and node >=18.

Core Capabilities¶

It performs six checks:

1. Version consistency: Whether the version between package.json and npm lock files is consistent.
2. Tag and remote status: Judged based on local existing origin/<branch> references, without git fetch.
3. CHANGELOG / Release notes: Check if it covers the current version.
4. Site / Frontend file version numbers: Judged by x.y.z literals in files matched by siteVersionGlobs.
5. Release pipeline hardcoding: Check if there are old version family literals that were missed.
6. Optional registry check: When adding --npm, request the registry once additionally, and read-only.

There are three types of output: human-readable text; --json machine-readable; exit code 0 means releaseable, 1 means blocking, 2 means only warnings. These can be directly integrated into CI or release scripts.

Criteria can be configured via .release-guard.json in the repository root, without changing code or hardcoding any project paths. Default behavior only reads local git, no internet; only adds --npm to request registry. After installation, the sidebar will show the “DeepWhale Release Guard” panel, fill in the repo path and click check, listing evidence and suggested actions item by item.

Installation and Enablement¶

The installation command given in the README is:

dsh plugin --profile web add @deepwhale-cn/dsh-release-guard

This command installs the plugin with the web profile. After installation, the sidebar will show the “DeepWhale Release Guard” panel; you can also use the command line directly. No need to manually concatenate dsh plugin add github:owner/repo.

Typical Usage¶

Command line usage is as follows:

dsh-release-guard /path/to/repo          # Human-readable
dsh-release-guard /path/to/repo --json   # Machine-readable
dsh-release-guard /path/to/repo --npm    # Additional registry check (online)
echo $?                                  # 0 releaseable / 1 blocking / 2 warnings

The four commands above correspond to human-readable output, machine-readable output, additional online check, and reading exit codes. --npm is the only path that goes online and requests the registry only once.

How to Configure Criteria¶

Default values only write general conventions, not recognizing any specific project. The repository root can place .release-guard.json, fields consistent with the README example:

{
  "versionFile": "package.json",
  "lockFiles": ["package-lock.json", "npm-shrinkwrap.json"],
  "changelog": "CHANGELOG.md",
  "notesFiles": ["assets/whatsnew.json", "whatsnew.json"],
  "siteVersionGlobs": ["index.html", "docs/**/*.html", "public/**/*.html"],
  "workflowGlobs": [".github/workflows/*.yml", ".github/workflows/*.yaml"],
  "tagPrefixes": ["v", ""],
  "ignoreDirs": ["node_modules", ".git", "dist", "build", "out", ".next", "coverage", "vendor"]
}

For repos that don’t use CHANGELOG, you can set changelog to null. If site version files are elsewhere, modify siteVersionGlobs; glob supports **, *, ?. Only recognizes 1.2.3 not v1.2.3, change tagPrefixes to [""]; if both are recognized, keep the default.

Self-testing¶

The self-test command built into the repository is:

bash tests/run.sh

The README states that it constructs three temporary repo fixtures, does not touch the real local repo, and does not go online. A clean repo must have exit code 0 (no blocking) and 0 (no warnings); a dirty repo must have at least 3 blocking, and evidence must include specific version numbers; a repo with only warnings must have exit code 2.

Suitable Scenarios and Notes¶

Suitable for maintainers who want to fix “what is missing” before release into machine-readable conclusions, and for scenarios where checks need to be integrated into CI. It does not judge code quality, run tests, or build, only checks if release metadata and files are self-consistent.

Note that the plugin runs with the permissions of the current dsh process, so you should check the source code and license before installing. The repository package.json states MIT, but you still need to verify the actual distribution content of different repositories yourself. It defaults to reading local git only, without git fetch; whether the remote has been pushed can only be judged based on local existing origin/<branch> references, and warnings will be given if not fetched.

Other boundaries: Pipeline hardcoding is judged by version family, only reporting old versions missed by oneself. When current is 1.0.64, only 1.0.x old literals are counted as blocking; other version families like electron 43.4.0, runtime 0.2.0-rc.2 will be ignored; pure comment lines, action references like @v4.1.0, runtime lines like node-version / DSH_ / runtime will also be skipped. Release notes support shapes like entry arrays, versions, releases, top-level flat, and keys starting with _ like _comment are ignored. Lock files currently only parse npm system’s package-lock.json / npm-shrinkwrap.json; pnpm, yarn lock structures can be extended via lockFiles as needed, currently not parsing. The README also states that users must comply with local laws and regulations and bear responsibility for the consequences of use.

Conclusion¶

Its value lies not in making release decisions for the team, but in turning the version consistency check most easily missed before release into a command, a piece of evidence, and three exit codes suitable for scripts.

Directory Page: https://www.skillhub.cn/plugins/feely0208/dsh-release-guard

GitHub: https://github.com/feely0208/dsh-release-guard