Repository navigation
Releases: timedomain1/dsh-mermaid-renderer
Release list
v1.3.0 — 离线可用 + 双宿主支持
[1.3.0] - 2026-10-11
新增
- 离线兜底:内联 Mermaid 引擎。引擎随
lib/client.js一起分发,断网或网络受限时图表仍可渲染。
引擎加载顺序变为:window.__DSH_MERMAID_URL__(自定义镜像)→ jsDelivr → unpkg → 内联引擎。 - 引擎末尾自带
globalThis["mermaid"] = …,内联后无需额外包装即可被发现。
变更
- 外部源加载加入 8 秒超时(
CDN_TIMEOUT_MS),离线时不再等待浏览器默认的长时间超时;
超时与网络错误一样,继续尝试下一个源。 - 引擎初始化逻辑抽为
initEngine(),外部源与内联引擎共用同一套美化默认值。
为什么引擎必须内联,而不能作为独立文件按需加载
DSH 每个插件只暴露一个资产路径 client.js:宿主路由形如
/plugins/${resource.id}/${resource.fileName},而 fileName 恒为 "client.js";CLI 侧更是直接硬编码。
package.json 里没有声明额外静态资源的字段;dsh.client.external 只对"已注册为客户端模块的包"生效,
对第三方普通库无效。
所以 3.4 MB 的引擎只能内联进 client.js,会计入该文件的体积(构建后约 3.43 MB)。
这是当前宿主架构下的取舍,不是实现上的偷懒。若将来官方支持插件附带静态资源,应改为按需拉取。
这 3.43 MB 会被反复下载吗?——不会
宿主对插件 bundle 的响应头是 cache-control: public, max-age=31536000, immutable,
且 bundle 的 URL 带内容指纹(combo revision)。因此:
| 场景 | 是否重新传输 |
|---|---|
| 不升级插件、反复打开或重启宿主 | 否——URL 未变,浏览器(含 Electron)直接用强缓存 |
| 升级插件(内容变化 → 指纹变化) | 是,仅一次;之后再次缓存 |
| 清空浏览器缓存 / 换浏览器 | 是,仅一次 |
| 桌面端(Junction 链接到本机源码) | 不经过网络,从本机磁盘读取 |
注意:插件的 bundle 位于启动清单的 application 预加载批次,与 dsh.client.immediately 无关——
immediately 决定的是"何时物化(执行)factory",不是"何时下载"。因此每个客户端插件的 bundle
都会随页面启动被请求一次,随后由缓存接管。
设计权衡记录(2026-10-11):曾考虑加一个"CDN 优先 / 内联优先"开关来减小首屏体积,最终否决——
开关本身会变成需要长期维护的配置项,而缓存在实际使用中已把代价摊薄到可忽略;
保持"默认离线可用"这一单一行为更简单可靠。
工程
- 引入构建步骤:
lib/client.src.js(可手改的模板)+.vendor/mermaid.min.js(已提交,构建可离线复现)
→scripts/build-client.mjs→lib/client.js(生成物,请勿手改)。 node scripts/build-client.mjs --check校验生成物是否与模板+引擎一致。node scripts/test-inline-engine.mjs:在全局作用域执行内联引擎,验证globalThis.mermaid、
initialize()、render()可用(改动引擎或升级 mermaid 后必须运行)。
安装
命令行网页端
dsh plugin --profile web add git+https://github.com/timedomain1/dsh-mermaid-renderer.git官方桌面端:应用内「插件」页 → 添加插件,填入
https://github.com/timedomain1/dsh-mermaid-renderer
装入后重启宿主(桌面端需完全退出再重开)。
兼容的 DSH 版本
| 宿主 | 版本(实测通过) |
|---|---|
命令行 dsh web |
0.1.5-rc.1 |
| 官方桌面端 | 0.2.0-rc.2 |
同一份代码同时支持两者——两个宿主共用同一套聊天界面与客户端插件契约。
完整版本历史与兼容性对照表见仓库
CHANGELOG.md。