How to use DSH-better-sidebar
The aggregate dual-mount test fixture included in the DSH-better-sidebar repository simulates the aggregate bundle preemptive mounting scenario, verifying that the plugin's own bundle patch automatically yields during repeated mounting to avoid crashes.
This article is auto-derived from indexed fields (wiki / faq / compatibility_json), not freshly AI-generated.
This article is derived from the plugin's already-indexed fields (wiki / faq / compatibility_json / readme), not freshly generated by AI. Source field is noted at the end of each section.
Quick start
aggregate-better-sidebar (DSH-better-sidebar Aggregate Mount Test Fixture)
— source: plugin_wiki.wiki_content
Install & verify
dsh plugin --profile web add github:omdsh-dev/DSH-better-sidebar#path:tests/fixtures/aggregate-better-sidebar
Run the command above in your DSH Web Profile. Then enable the plugin in the plugin list.
— source: plugins.install
Key points
- 🗂️ 文件工作台:资源管理器(懒加载目录树;软链接按目标类型展示——目录软链接可展开、失效链接标红)+ CodeMirror 编辑器;图片 / Markdown(含 Mermaid 图表,strict 安全渲染 + 点击放大)/ HTML / PDF / Office 内联预览
- 🌐 内嵌浏览器:多开网页 tab,后退 / 前进 / 刷新;内容运行在沙箱 iframe;外链默认按协议分流——HTTP 在侧边栏打开、HTTPS 走系统浏览器(设置页可分别调整)
- 💻 真实终端:xterm.js + node-pty 真实 shell,断线重连回放;可选为模型注入
terminal_*工具 - 🌿 Git 面板:真 diff + VSCode 式 diff tab、历史、右键暂存 / 提交 / 还原
- 🧩 后台任务页:subagent 拓扑 + 后台任务(退出码 / 实时输出 / 强制终止)
— source: plugin_wiki.readme_en (fallback readme_raw)
FAQ
Is this package intended for regular users to install?
No. It is a CI test fixture bundled with the DSH-better-sidebar repository (version pinned to 0.0.0, private: true), not published to npm and should not be installed via the plugin marketplace; the actual usage is the repository's own scripts/e2e-aggregate-mount.sh script that runs npm pack in CI and then installs it into a scratch profile using a file: path.
What is its relationship with the main plugin dsh-better-sidebar?
It is a shell package with only one cordis.patch.yml that uses insert to mount the bundle named dsh-better-sidebar to cordis with a separate entry id (aggregate-better-sidebar); cordis thus sees two different entry ids trying to mount the same package name, and this conflict triggers the main plugin's own yield guard expression (introduced in PR #200).
What can be seen on the interface after installing it?
Nothing can be seen. lib/index.js is an empty no-op apply(), the package itself does not register any UI or expose any services; it merely "reserves" a mount declaration for the main plugin, the actual sidebar interface is provided by the main plugin (or aggregate row).
What bug is this fixture preventing?
It prevents the "duplicate prefix route" crash fixed by PR #200: if an aggregate bundle (like dsh-web-ui-all) pre-emptively mounts dsh-better-sidebar with a separate id, and the main plugin's bundle patches in later, if both lines take effect they will register the /sidebar/api prefix route twice, causing the entire dsh web to fail to start; the main plugin's cordis.patch.yml guard expression detects that a mount with the same package name is already enabled and automatically disables its own line.
Why does this fixture use file: path instead of github: path for installation?
scripts/e2e-aggregate-mount.sh first uses npm pack to package the fixture into a tarball and then uses file: to install it into a fresh scratch profile, aiming to run an end-to-end smoke test with a real installation order (aggregate first, main plugin second); the installation command shown in README is just a syntax supported by the installer, this package itself has no end-user-facing functionality.
Can I install it in a production profile?
Technically yes (it is a valid npm package), but it makes no sense. The package name is fixture-aggregate-better-sidebar, version 0.0.0, private: true, installing it will only add one more mount declaration to your cordis patch without bringing any new functionality, and may instead trigger the main plugin's yield guard.
How do I debug when CI fails?
Check e2e-aggregate-mount.sh: it looks for "duplicate prefix route" in ERR_LOG/OUT_LOG (indicating the yield guard failed), makes a POST to /sidebar/api/terminal.deps expecting response ok:true, expects 404 for unknown methods; if any assertion fails the script dies and prints 200 bytes of response headers for troubleshooting.
How do regular users know this fixture exists?
See the "Aggregate double-mount auto-yield" entry in the main repository's README_EN.md:81, and the "Two sidebars on the page" row in the README troubleshooting table—both explicitly mention that the plugin yields in aggregate package scenarios, and this fixture is the fixed reproducer for this behavior in CI.
— source: plugin_wiki.faq_json
Compatibility
- DSH: 0.1.0-rc.8+
- Node: 未声明
- Platforms: 跨平台
— source: plugin_wiki.compatibility_json
Pitfalls
Review the upstream repo before installing. This guide is auto-derived from indexed fields and may lag the latest release. If anything contradicts the official docs, treat the upstream source as authoritative.
— source: general rule