Introduction¶
The philosophy of DSH is “everything is a plugin”. Plugins are injected into the UI via the cordis.patch.yml in the profile, and then loaded by the Host declaring in package.json. The problem is: to know exactly what a plugin declares and which files are installed, you have to go back to the command line to browse the profile directory and node_modules; there is no entry point in the UI. For troubleshooting high-frequency issues like “why this plugin changed a certain tree,” this serves as a frequent starting point.
dsh-plugin-inspector (package name @liuweibing7/dsh-plugin-inspector, version 1.0.0, MIT, author liuweibing7) brings this capability into the plugin detail page: the maintainer’s tool category is Client-side, and the browser-side adds a new inspector section inside the plugin page, listing the original YAML used for declaration and the actual installed code files in two tabs. Currently, the GitHub stars count is 0, making it a very new and small utility.
What is this plugin¶
One-sentence positioning: A DSH client-side plugin that adds an inspector section to the plugin detail page in the http:// Web GUI, displaying which YAML patch entries the target plugin declares and which code files are installed behind the scenes. It solves the troubleshooting problem of “plugin declaration vs. actual files mismatch,” allowing you to read profile and package directories without leaving the interface.
It is not a plugin manager, nor does it handle installation, enabling, or uninstallation. It is read-only and only displays.
Core Features¶
The following two sections are organized according to the description in the README, divided into “Declaration” and “Code”.
Declaration Tab: How the plugin is declared¶
- Reads the current profile’s
cordis.patch.ymland the plugin bundle’s built-incordis.patch.yml, locating the precise YAML list-item declaring the plugin. - Each segment displays the source file path, specific text, corresponding entry, and provides a view of the entire file.
- The page loads the declaration immediately upon opening; no need to switch tabs.
Code Tab: What files are installed by the plugin¶
- Lists files installed by the plugin:
package.json, Host entry point, browser bundle,src/source code released with the package, README, and type entry points. - YAML, JSON, JS/TS, and Markdown all have syntax highlighting.
- Markdown is rendered by default, with a rendered/raw toggle provided.
- This tab only initiates loading when you open it for the first time; it is not fetched by default.
- The browser-side cannot read files directly; all text comes from the Host-side interface, which is the part expanded in the “Workflow” section below.
Installation and Enablement¶
First, clarify the prerequisites: This capability requires DSH Web GUI to run under http://, and this block is unavailable inside file:// shells; also, the target plugin must have a corresponding page (bundle page, line config page, or official plugin page), otherwise the inspector cannot be mounted.
Remote installation (from README):
dsh plugin --profile <profile> add github:liuweibing7/dsh-plugin-inspector
Local checkout installation:
dsh plugin --profile <profile> add /path/to/dsh-plugin-inspector
After installation, restart or refresh the Web UI based on the host situation. The plugin itself registers a detail page block (slot plugins.detail.section, id plugin-inspector) and a Host route (/plugin-inspector), without modifying other UI.
Typical Usage¶
After installation, open any plugin detail page in the Plugins interface and scroll to the inspector section. The screenshots given by the README show three moments: the inspector section in the plugin detail page, the Declaration tab (original yaml and file paths side by side), and the Code tab (syntax highlighting and rendered/raw toggle).
If you want to troubleshoot why a plugin is effective, the operation path is: open its detail page -> first look at Declaration, confirm which patch entry brought it in -> then switch to Code, look at actual entry points and bundle vs declaration consistency. Analogy to manual troubleshooting is grepping YAML in the profile directory and flipping through package.json in node_modules; these two steps are the inspector’s alternative.
Workflow¶
The README describes the respective responsibilities of the two ends:
- Host half (
index.js,blocks.js) registers a same-originPOST /plugin-inspectorroute, reads the current profile’s patch file and installed package files, returns JSON, and does no writing.blocks.jsis responsible for precisely extracting YAML list-items. - Browser half (
client.js) registersplugins.detail.sectionand renders two tabs, with all text coming from the Host route. - The route rejects cross-origin requests and does not set CORS headers; the service is provided by the Host’s loopback web server.
- Declaration and code payloads are cached within the page up to 10 targets; the Code tab only requests on first open.
Scope and Security Considerations¶
This part directly relates to whether you can use it confidently in a production environment, and the README has a clear statement:
- This is a local troubleshooting tool. It will read the current profile’s
cordis.patch.yml/cordis.yml/ patch overlays, as well as thepackage.jsonand installed files of the plugin you opened. - It does not write files, does not send anything to the network, and does not execute plugin code.
- When rendering Markdown, the output is escaped HTML: raw HTML in the README is displayed as text,
javascript:links are not rendered into clickable links, and links all open in new tabs. - Limited by the permissions of the dsh process itself, what it can read is exactly what you see when you start DSH. If strict auditing is needed before installation, you should still check the plugin source code and license yourself (this package is MIT), rather than defaulting to trust.
Boundaries and Known Limitations¶
- Most packages only publish built
lib/*.js, TypeScript source code is only visible when the package releasessrc/(e.g.,@deepseek-ai/cordis). - Single files are truncated to 256 KiB, overall response limit is 1.6 MiB, maximum return is 16 files; highlighting only covers the first 120 KiB of a single segment.
- Markdown rendering covers headings, paragraphs, lists, blockquotes, fences/inline code, links, emphasis, horizontal rules, and simple tables; nested lists are flattened, images are converted to links, and raw HTML is escaped.
- The
file://runtime is unavailable.
Development Form¶
No build steps. The package is pure ESM plus a hand-written browser bundle, loaded by window.__ModuleLoader__. Key file breakdown is as follows:
package.json dsh.bundle.patch + dsh.client + exports
cordis.patch.yml Insert plugin-inspector row
index.js Host half: route + profile/patch/package read
blocks.js Precise YAML list-item extraction
client.js Browser half: slot, tabs, highlighting, Markdown
locale/*.json Display metadata (title/description)
icon.svg Plugin icon
In package.json, dsh.client declares platform: web and immediately: true, injecting @deepseek-ai/dsh-client-locale; dsh.bundle.patch points to ./cordis.patch.yml.
Conclusion¶
dsh-plugin-inspector moves the two things “what the plugin declares and what files are installed” into the detail page, saving the round trip of browsing profile and node_modules. It is read-only, doesn’t connect to the internet, doesn’t execute code, belongs to a troubleshooting auxiliary tool, not a plugin management solution.
Directory page: https://www.skillhub.cn/plugins/liuweibing7/dsh-plugin-inspector
GitHub: https://github.com/liuweibing7/dsh-plugin-inspector
It is worth noting that the community plugin directory is an independent site and has no official affiliation with DeepSeek / Fudan.
