@dsh-remote/relay 3.1.3 → 3.1.5

package/README.md

@@ -1,14 +1,14 @@
 # @dsh-remote/relay
 
 DSH Remote Control 的**零知识 WebSocket 中继**：在宿主插件与已配对的手机之间转发**密封记录**，
-只认帧名 / 会话 id / 能力协商，**从不解析载荷**——密文对它就是一个 base64 字符串。
+只认帧名 / 会话 id / 协议版本闸，**从不解析载荷**——密文对它就是一个 base64 字符串。
 
 生产形态是**单文件产物** `dist/bundle/main.js`（`ws` / `zod` / 协议层全部内联，运行时零依赖）；
 部署只有两种：拷这个单文件 + 起进程（systemd / docker / nginx 配方见下），或从源码构建。
 
 ## 自托管
 
-完整配方（环境变量表、systemd / docker / nginx、排错、升级与回滚）见
+完整配方（环境变量表、systemd / docker / nginx、排错、升级）见
 [`docs/SELF-HOSTING.md`](docs/SELF-HOSTING.md)。最速验证：
 
 ```sh

package/deploy/README.md

@@ -20,7 +20,7 @@
 于是生产只有"拷一个文件 + 一个 env 文件"，没有 `npm install`，也就没有
 "服务器上的依赖树和 CI 不一样"这一类故障。
 
-> 完整的环境变量表、日志契约、重启语义、升级回滚见 [`../docs/SELF-HOSTING.md`](../docs/SELF-HOSTING.md)。
+> 完整的环境变量表、日志契约、重启语义、升级见 [`../docs/SELF-HOSTING.md`](../docs/SELF-HOSTING.md)。
 
 ## 从零复现
 

package/deploy/docker/Dockerfile

@@ -41,67 +41,41 @@
 #      （deploy/docker/README.md 有完整的离线步骤；生产那次就是这么发的）。
 #
 # Node 22 与 CI、与 HANDOFF 的工具链口径一致（pnpm 11 要求 >= 22.13）。
+#
+# ## 2026-10-13（3.1.5 起）：这份 Dockerfile 回到**单仓形态**
+#
+# 3.1.3/3.1.4 那两次部署用的是**伞仓上下文**（COPY 带 `packages/` 前缀、compose 的
+# `context: ../..` 指到 monorepo 根）——因为那时服务器上摆的是整棵伞仓树。
+# 2026-10-13 用户裁决：服务器改成**单仓部署**（部署源 = 本仓，不再摆伞仓）。
+# 本仓与伞仓共用这份文件路径（`deploy/docker/Dockerfile`），但**两边各有一份内容**：
+# 伞仓那份（`/deploy/docker/`）保持 monorepo 形态给伞仓构建用；本仓这份从现在是
+# 独立仓形态——`COPY package.json pnpm-lock.yaml ./` 拷的是**本包**清单，
+# `@dsh-remote/protocol` 从 **npm** 装（devDependency，发版顺序 protocol 先行），
+# `pnpm-lock.yaml` 由 `scripts/split-repos.mjs` 在暂存时生成并随仓跟踪（CI 的
+# `--frozen-lockfile` 依赖它）。两份 Dockerfile 的差异只有 build 阶段的 COPY 路径，
+# runtime 阶段逐字相同。
 FROM node:22-alpine AS build
 WORKDIR /src
 
-# 先只拷锁文件再装：pnpm 的安装缓存按 lockfile 命中，改 src 不必重装依赖树。
+# 先只拷清单与锁再装：安装缓存按 lockfile 命中，改 src 不必重装依赖树。
 # --frozen-lockfile 是刻意的——镜像里装的必须与提交的 lockfile 逐位一致，
 # "构建时顺手升了某个传递依赖"这类漂移正是要消掉的。
-#
-# ## v3 单仓：这里的 COPY 必须带 packages/ 前缀（2026-10-08 修）
-#
-# v2 时这个仓是**独立仓**，build 上下文（compose 的 `context: ../..`）就是本仓根，
-# 所以 `COPY package.json pnpm-lock.yaml pnpm-workspace.yaml ./` 拷的是"本包 + 本包锁"。
-# v3 变成 monorepo 后，同一行拷的是 **monorepo 根**的三个文件——而根 package.json 里
-# 没有 relay 的依赖，于是 pnpm 报的错是「lockfile 里有 ^22.9.0、manifest 要 ^26.6.3」
-# 这类**看起来毫不相关**的 mismatch（真实原因：那份 package.json 不是这个包的）。
-#
-# 症状与判据：`docker compose build` 失败，而 `pnpm install` 在本机完全正常。
-# 所以下面显式列出三个路径，让"上下文是单仓根"这件事变成 Dockerfile 自己保证的。
-# ⚠️ 下面几行的行尾**不许带注释** —— Dockerfile 会把 `#` 之后的内容也当成拷贝路径
-# （报错形态：`"/需要它要解": not found`，看起来像文件不存在，其��是把注释当路径了）。
+# ⚠️ 下面几行的行尾**不许带注释** —— Dockerfile 会把 `#` 之后的内容也当成拷贝路径。
 # 要说明就写在上一行。
-COPY pnpm-workspace.yaml ./
-COPY pnpm-lock.yaml ./
-# monorepo 根清单：pnpm 需要它来解 workspace（里面没有 relay 的依赖，只负责解析结构）
 COPY package.json ./
+COPY pnpm-lock.yaml ./
 #
-# ⚠️ **pnpm-workspace.yaml 声明的每一个包都要有 package.json 在场**，少一个都不行。
-# 缺的那几个不会报"文件不存在"，而是报 `specifiers in the lockfile don't match`，
-# 并把**缺的包的依赖名**列出来（第一次栽在这里：漏了 plugin/client/e2e，于是报错说
-# 「lockfile 有 ^22.9.0、manifest 要 ^26.6.3」——那是 plugin 的 @types/node，
-# 与 relay 一点关系都没有 ⇒ 看起来像 lockfile 坏了，其��是清单没拷全）。
-# 镜像只需要 relay + protocol 的源码，但**清单必须全在场**，否则 pnpm 在 install 阶段就退出了。
-COPY packages/relay/package.json ./packages/relay/
-COPY packages/protocol/package.json ./packages/protocol/
-#
-# ⚠️ **不需要**把 workspace 里其他包（plugin / client / e2e）的 package.json 也拷进来。
-# 我一度以为"声明的包必须清单齐备"，为此加了三条 COPY —— 那三条**无效**：
-# 删掉之后 `pnpm install --frozen-lockfile` 照样通过（2026-10-08 在服务器上实测过：
-# 只放 protocol + relay 两份清单，frozen 检查顺利过，只在下一步因缺 protocol 的
-# tsconfig 而失败）。pnpm 只校验**它要解析的那些 importer**。
-#
-# 那次「lockfile 有 ^22.9.0、manifest 要 ^26.6.3」的 mismatch 真相不是"清单没拷全"，
-# 而是**根 package.json 被污染**：上传源码时用 `tar xzf`，relay 的 package.json
-# 覆盖到了仓库根，于是 pnpm 拿 relay 的依赖去比根的 lock ⇒ 报出 relay 的依赖名。
-# ⇒ **报错指错地方时，先怀疑"文件被覆盖"，别急着加 COPY。**
-#
-# protocol 的 src + tsconfig 必须在 install **之前**进来：
-# 它的 `prepare: tsc -p tsconfig.json` 是 install 生命周期的一环，
-# 顺序写反的报错是 `TS5058: path does not exist`，出现在 install 阶段。
-COPY packages/protocol/tsconfig.json ./packages/protocol/
-COPY packages/protocol/src ./packages/protocol/src
+# `@dsh-remote/protocol` 是 devDependency、从 **npm** 装（不再是 workspace 软链）：
+# 单仓里没有它的源码，也不需要——它对 runtime 是零依赖（bundle 全内联）。
+# 发版顺序因此必须是 **protocol 先发**，本仓构建才能锁到同版本。
+# 锁文件由 `scripts/split-repos.mjs` 暂存时 `pnpm install` 生成并随仓跟踪；
+# 在伞仓里它不存在（伞仓由根锁文件管），这是"两边各有一份内容"的一部分。
 RUN corepack enable && pnpm install --frozen-lockfile
 
-COPY packages/relay/tsconfig.json ./packages/relay/
-COPY packages/relay/src ./packages/relay/src
-COPY packages/relay/scripts ./packages/relay/scripts
-# protocol 必须**先构建**：它是 workspace 依赖，`pnpm install` 只软链它的 package.json，
-# 而 bundle 脚本按 node_modules 解析 ⇒ 拿到的必须是 `dist/src/**`（main 字段指向那里）。
-# 少这一步的报错形态是 esbuild 找不到 `@dsh-remote/protocol/dist/src/index.js`。
-RUN pnpm --filter @dsh-remote/protocol build
-# 在 relay 包目录里构建：它的 tsconfig 与 bundle 脚本都以包根为基准
-WORKDIR /src/packages/relay
+COPY tsconfig.json ./
+COPY src ./src
+COPY scripts ./scripts
+# tsconfig/bundle 脚本都以仓根为基准（单仓形态：仓根就是包根）
 RUN pnpm build
 
 # 产物级断言。两条取自 tests/bundle.test.mjs 的同款断言，写在这里是因为
@@ -119,7 +93,7 @@ ARG VCS_REF=unknown
 LABEL org.opencontainers.image.title="dsh-remote-relay" org.opencontainers.image.description="Zero-knowledge WebSocket relay for DSH Remote Control" org.opencontainers.image.source="https://github.com/providcc/dsh-remote-server" org.opencontainers.image.licenses="MIT" org.opencontainers.image.version="${DRC_VERSION}" org.opencontainers.image.revision="${VCS_REF}"
 
 WORKDIR /app
-COPY --from=build /src/packages/relay/dist/bundle/main.js /app/relay.mjs
+COPY --from=build /src/dist/bundle/main.js /app/relay.mjs
 
 # 只有这两个。**故意不设 DRC_STATE_FILE**：镜像里的默认值要与裸机（systemd 单元）一致——
 # 不配就是纯内存、配了才落盘。落盘路径属于"部署形态"而不是"程序形态"，它与卷是一对，

package/deploy/docker/README.md

@@ -57,20 +57,17 @@ docker compose … logs relay | jq 'select(.msg=="counters")'
 json-file 轮转（`max-size: 10m` / `max-file: 5`）。要长期留存就装一个日志驱动转发出去，
 别依赖 `docker logs`。
 
-## 升级与回滚
+## 升级
 
 ```sh
 # 升级：构建 → 重启 → 看版本号变了没有
 docker compose -f deploy/docker/compose.yaml up -d --build
 curl -s http://127.0.0.1:8787/healthz | grep -o '"version":"[^"]*"'
-
-# 回滚：把标签切回去再 up（镜像还在本地）
-docker tag dsh-remote-relay:2.0.14 dsh-remote-relay:2.0.15
-docker compose -f deploy/docker/compose.yaml up -d
 ```
 
-**回滚必须成对**（中继产物 + 主机插件产物）：两代握手帧名不兼容，只回滚一边会
-"永远配不上对"或"静默不上线"。见 `../SELF-HOSTING.md` §10.2 的对照表。
+三端（中继 / 宿主插件 / 小程序）必须升到**同一协议版本**：落后的一端会在 `hello` 那一刻
+被明确拒掉（`unsupported_protocol`）。⚠️ 2026-10-11 晚：原来这里还写着一套"成对回滚 +
+两代兼容矩阵"，随能力位与版本协商机制一起删掉了 —— 没有老用户，不需要回滚路径。
 
 ## 拉不到 Docker Hub 怎么办