dspack CLI

别名：@dsh-packforge/cli、打包命令行、整合包命令行、dspack

dsh-packforge-app 里的命令行入口（包名 @dsh-packforge/cli，bin 名 dspack，v0.1.1，Node ≥ 20）：把「导出 .dspack、离线看一眼、装进 profile、浏览市场」这四件事做进脚本与 CI。

一句话

dspack 是「在 DSH 之外」操作整合包的那把命令行扳手。 它和 plugin/2 的分工很干净：装进 DSH 之后日常用插件，装机之前批量做（导出、预览、校验、灌进 CI）用 CLI。

它有哪些子命令

实测 @dsh-packforge/cli v0.1.1 的 HELP 文本，一共 10 条命令：

命令	作用	关键选项
`list`	列出本机可导出的 profile（经典 `~/.dsh` 与启动器实例都扫）	—
`homes`	列出本机 DSH_HOME 实例（dshhome 导出 / 安装的目标）	—
`pack <profile\|dir>`	把单个 profile 导出成 `.dspack`	`--repo`（改出源仓库）、`--content`、`--dsh-version`、`--out`、`--force`
`pack-home <home>`	把整个 DSH_HOME 导出成 `.dspack`（dshhome 形态）	`--default-profile`、其余同上
`inspect <profile>`	打包前预览：将包含/排除哪些文件、manifest 长什么样	`--json`
`view <source>`	看一个已有的 `.dspack`（本地路径或 URL），报出合法性、层栈数、依赖数	`--json`
`install <source>`	安装整合包：解包 → `pnpm install` → 对账	`--dry-run`、`--no-install`、`--sha256`、`--size`、`--profiles-root`、`--home`、`--registry`、`--force`、`--timeout`
`market [<index>]`	列市场索引；`--detail <name\|id>` 懒加载某个包的完整 manifest 与 README	`--json`、`--detail`；索引地址可用 `DSHPACK_MARKET_INDEX` 覆盖
`version` / `help`	版本与帮助	—

两个细节值得记：pack 的 dshVersion 取值优先级是 --dsh-version > 工作区 .dshpkcfg > 本机最新已装；install 默认还会做一次对账，把「manifest 依赖了但没装上」的包名报出来（缺的会自动补进），这比「装完没报错」有用得多。

三种装法

路子	命令	状态
仓库内全局链接	`cd packages/cli && pnpm link --global`，之后任意目录敲 `dspack --help`	文档明写（docs/发布.md §2）；本轮未实测执行
Windows 一键安装包	安装包内含 `cli/dspack.exe`（Node SEA 单文件）并由 NSIS 段把它加进 PATH	配置可查（`packages/gui/package.json` 的 `extraResources` + `nsis.include`）；本轮未实测安装
npm 全局安装	暂无	实测 2026-10-02：registry 上找不到 `@dsh-packforge/cli`（404）

所以「npm i -g @dsh-packforge/cli」这句话现在不成立；要写进脚本，用 node <仓库>/packages/cli/bin/dspack.js 或先 pnpm link --global。

它在工具链里的位置

它与 GUI 是同一个 monorepo 的两个宿主：core 是主机无关的引擎（不 import node:fs/node:crypto，I/O 全走 Host 注入），CLI 只是薄门面，因此「GUI 会做的事」和「CLI 会做的事」不该出现两种答案。
发布链路上的位置：skill/1 的路径 A 就是 dspack pack --repo → 得到源仓库与 release/ 成品区 → 再由 gh 建仓发 Release。
本站的一贯提醒（分区 howto 的原话）：做过之后仍建议用 dsh --profile <name> --dump-config 对一遍真实装配结果，别只信预览。CLI 的 view / inspect 看的是包，不是运行中的树。

未核实 / 未声明

实际跑起来的输出：本轮读的是 packages/cli/src/cli.js 的源码与 HELP 文本（v0.1.1），没有执行任何子命令；上面表格里的选项名与行为描述都来自源码，不是实测输出。
npm 发布状态：只测了 registry 的一个 URL 返回 404（2026-10-02），没有查 dist-tags、也没有查是否发在别的 scope 下。包内 publishConfig 与文档都指向「准备发」，所以「以后会不会有 npm 安装命令」未核实。
Windows 安装包里的 dspack.exe 版本：未核实。它是构建期用 Node SEA 从当前仓库打出来的，配置在 packages/gui/package.json；本轮没有解包安装包核对它的版本号是否等于 0.1.1。
install 在 dshhome 形态下的行为：源码里两条路径（profile / dshhome）分开处理，但本站没有真实的 dshhome 样本，所以只核实了 profile 这条。
许可证：见 licenseRefs——包内声明有，仓库根未读。

谁引用了这一条

信息表

authors: DSH-PackForge（开发团队）
category: tooling.pack
form: cli
install: 已核实两条路，而非 npm 安装——① 仓库内 cd packages/cli && pnpm link --global（docs/发布.md §2）；② Windows 一键安装包把 Node SEA 打出的单文件 dspack.exe 作为 cli/dspack.exe 附上并加进 PATH（packages/gui/package.json 的 extraResources 与 nsis.include）。npm 上取不到这个包，见正文「三种装法」。
language: javascript
licenseRefs: MIT · id: MIT · note: @dsh-packforge/cli 的 package.json 写 MIT（实测 2026-10-02）；仓库根 LICENSE 本轮未读取，整仓许可口径未核实。
provides: 导出：pack（单个 profile）与 pack-home（整个 DSH_HOME），都能直接出 .dspack，并回报大小与 sha256、只读预览：inspect（打包前看将包含/排除哪些文件）与 view（看一个已有的 .dspack，本地路径或 URL 都行）、安装：install，解包落盘后跑 pnpm install 重建依赖，再对账并回报缺失/自动补进的包、市场：market 列出索引条目，market --detail <name|id> 懒加载某个包的完整 manifest 与 README、仓库导出：pack --repo 产出「源仓库 + release/ 成品区（.dspack 与同名 .sha256 侧车）」，这正是发布技能路径 A 用的那一步
repo: DSH-PackForge/dsh-packforge-app
requires: Node.js 20 或更高（@dsh-packforge/cli 的 engines 字段）、pnpm 在 PATH 上——install 子命令内部直接调 pnpm install（core 的 pnpmInstall）、本机至少有一个可发现的 profile 或 DSH_HOME（list / homes / inspect / pack 都先扫这两处）、网络（仅当 install/view/market 的入参是 URL，或安装时要拉依赖）
titleEn: dspack CLI
updatedAt: 2026-10-02

标签安装打包工具链命令行

被 2 条词条引用

属性

分类 tooling.pack 形态 cli 语言 javascript 上游 DSH-PackForge/dsh-packforge-app 最后更新 2026-10-02

开发者 / 团队（1）

DSH-PackForge 开发团队

支持的 DSH 版本

本站尚未收录它的 DSH 版本声明。

按标签浏览：安装（2） · 打包（2）