typert-generator 0.0.1-rc.1 does not recognize DSH 0.1.1-rc.2 Remote API

[BIGBEAR-cjx]

Summary

@deepseek-ai/dsh-typert-generator@0.0.1-rc.1 does not recognize the Remote service API exposed by @deepseek-ai/dsh@0.1.1-rc.2.

The generator appears to detect the older GatewayService / bindTypeRTGateway pattern, while the current DSH Typert packages expose TypertRemoteService / bindTypertRemote. As a result, an external package following the current API cannot produce the strict generated Remote contribution required by the Client gateway.

Versions

• @deepseek-ai/dsh: 0.1.1-rc.2 (current latest and next npm tags)
• @deepseek-ai/dsh-typert-generator: 0.0.1-rc.1
• Node.js: 22.23.2
• pnpm: 11.7.0

Reproduction

1. Create a package under the documented workspace layout: packages/<package>/package.json.
2. Add the documented Host/Client TypeScript project references (tsconfig.host.json and tsconfig.client.json).
3. Define a read-only Remote service using the API exported by the current DSH packages: TypertRemoteService, bindTypertRemote, and annotated Remote methods.
4. Run @deepseek-ai/dsh-typert-generator@0.0.1-rc.1 against the workspace.

The generator discovers the package and service. Its intermediate model contains the service and annotated methods, but the generated invocations list is empty. Validation then fails with:

publishes Remote artifacts but has no Remote methods

Inspection of the installed generator shows matching for the older GatewayService / bindTypeRTGateway form. Inspection of the DSH 0.1.1-rc.2 declarations shows only the newer TypertRemoteService / bindTypertRemote form for this contract.

Expected behavior

The published generator should recognize the Remote API exported by the current published DSH version and emit a non-empty strict Remote contribution, or the project should publish/document a compatible version matrix.

Impact

External dsh.client plugins cannot safely expose a typed Host Remote while following the current published packages. The documented Client gateway requires strict generated contributions, so the alternatives would be an unsupported generator fork or a private transport, neither of which is suitable for a public plugin.

Requested resolution

Please either:

1. publish a generator version that recognizes TypertRemoteService and bindTypertRemote; or
2. publish a DSH/package set that matches the existing generator and document the exact compatible versions.

I can provide a minimized reproduction repository if that would help.

[weijiafu14]

这个大概率不是生成器不支持新 API，是你装到了一个一年前的版本。

@deepseek-ai/dsh-typert-generator 的 npm dist-tag 现状（我刚查的）：

latest : 0.0.1-rc.1      ← 你装到的这个
next   : 0.1.1-rc.2      ← 与 DSH 0.1.1-rc.2 同版本线

已发布的版本里有 0.1.0-rc.2/3/6/7/8、0.1.1-rc.1、0.1.1-rc.2，但 latest 从来没挪过去。所以 npm i -D @deepseek-ai/dsh-typert-generator（不指定版本）会走 npm 默认的 latest 解析，装到 0.0.1-rc.1——它当然只认识那个年代的 GatewayService / bindTypeRTGateway。

试试显式指定：

npm i -D @deepseek-ai/dsh-typert-generator@0.1.1-rc.2
# 或 @next

这是一个系统性的发布流程问题，不是这一个包的事。 我核过其它几个：@deepseek-ai/dsh-base、dsh-client-ui-sidebar、dsh-web-search-deepseek 的 latest 也都停在 0.0.1-rc.x，而真实版本在 next 下——只有主包 @deepseek-ai/dsh 的 latest 是对的。同一根因已有报告：#2233、#3098（后者楼主确认显式指定版本号就解决了）。

建议：如果换版本后问题消失，这帖可以转成"给所有子包的 latest 打对标签"的诉求并入 #2233——那比逐个包报兼容问题有用得多，而且这个坑会持续劝退每一个想写插件的人。

---

顺带一句，如果换完版本你仍要往 typert Remote 上接：仓外插件其实不一定要走它。typert Remote 是一等公民的代码生成契约；插件想给自己的浏览器半边供数据，用 ctx.webServer.register 挂自有路由就够了，不受生成器版本约束。我维护的东西的 Web 管理页就是这么做的（真机跑通）。当然，如果你就是要生成严格的 Remote 契约，那这条不适用——那还是得等生成器版本对上。

利益相关：我维护 pi2dsh。上面第一节（版本标签）跟我的东西完全无关，是可以自己 npm view 复核的事实。

[BIGBEAR-cjx]

Thanks for pointing out the dist-tag skew. I re-ran the probe with the exact published version @deepseek-ai/dsh-typert-generator@0.1.1-rc.2 (integrity-pinned), so the old latest version is no longer involved.

The external-plugin failure still reproduces, and the remaining cause is narrower:

• A minimal packages/<plugin> workspace is discovered correctly.
• Its Context service extending TypertRemoteService is discovered.
• Its top-level concrete method uses @Remote('probe') imported from @deepseek-ai/dsh-typert-protocol@0.1.1-rc.2.
• TypeScript resolves Remote to the published protocol declaration under node_modules/.../lib/types/index.d.ts.
• WorkspaceAnalyzer still returns invocations: [], and generation fails with publishes Remote artifacts but has no Remote methods.

Source-level inspection explains the difference between the Harness monorepo and an external npm consumer. In generator 0.1.1-rc.2, isTypeMetaSymbol() accepts a protocol symbol only when either:

1. registrationForFile(declarationFile)?.name === '@deepseek-ai/dsh-typert-protocol'; or
2. the declaration is enclosed in declare module '@deepseek-ai/dsh-typert-protocol'.

The Harness Host build explicitly references packages/typert/protocol, so protocol source is a registered workspace package there. A normal external plugin resolves the same symbol from the published package's .d.ts in node_modules, which satisfies neither condition.

I now have a deterministic regression test that creates an isolated external plugin workspace, links the published protocol and Cordis packages, confirms service discovery, then asserts the empty invocation list and exact generation error.

Could isTypeMetaSymbol() also recognize declarations resolved from the published @deepseek-ai/dsh-typert-protocol package, without requiring that package's source to be part of the consumer workspace? I can publish a minimal reproduction repository if useful.

[me93-ghb]

Same underlying issue as #2981.