lib.dom.d.ts: Transformer is missing the `cancel` member that WHATWG Streams defines
维护者通常 1 天内回复
还没有人认领这个 Issue。
- #65023 来自 @timurzvural —— 已关闭,未合并
评估
- 难度
- 3/5
- 预计耗时
- 半天
- 新手友好度
- 52/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- typescript
- 领域
- tooling
调研方向
Start by reading the generated DOM and WebWorker declarations for Transformer, especially dom.generated.d.ts and lib.webworker.d.ts, and check how their callback types are defined. The issue reports a closed, unmerged pull request, so first review that work and the current declaration generation flow. Done means both interfaces expose the standard cancel member with an appropriate callback type and the reported TypeScript reproduction compiles.
由索引模型根据 Issue 内容生成。
描述
Summary
lib.dom.d.ts declares interface Transformer without the cancel member, but
the WHATWG Streams standard includes it and Node implements it. Any
new TransformStream({ ..., cancel() {} }) therefore fails to compile with
TS2353, even though the handler is valid and gets called when the readable side
is cancelled.
Reproduced on TypeScript 6.0.3 and 7.0.2.
Standards reference
WHATWG Streams, Transformer dictionary
(https://streams.spec.whatwg.org/#dictdef-transformer) defines six members:
start, transform, flush, cancel, readableType, writableType
lib.dom.d.ts declares five of the six. cancel is missing:
interface Transformer<I = any, O = any> {
flush?: TransformerFlushCallback<O>;
readableType?: undefined;
start?: TransformerStartCallback<O>;
transform?: TransformerTransformCallback<I, O>;
writableType?: undefined;
}
Minimal reproduction
const ts = new TransformStream<Uint8Array, Uint8Array>({
transform(chunk, controller) { controller.enqueue(chunk); },
cancel() { /* client disconnected */ },
});
export { ts };
$ tsc --noEmit --target es2022 --lib dom,es2022 probe.ts
probe.ts(3,3): error TS2353: Object literal may only specify known properties,
and 'cancel' does not exist in type
'Transformer<Uint8Array<ArrayBufferLike>, Uint8Array<ArrayBufferLike>>'.
Identical output on 6.0.3 and 7.0.2.
The runtime does call it
Node 24.18.0, stream/web:
const ts = new TransformStream({
transform(c, ctrl) { ctrl.enqueue(c); },
cancel(reason) { console.log("transformer.cancel INVOKED", reason); },
});
await ts.readable.cancel("client-disconnect");
// -> transformer.cancel INVOKED client-disconnect
So cancel is not a dead optional member. It is the only hook that fires when
the readable side is cancelled, which for an SSE proxy is exactly the
client-disconnect case. Handlers here typically clear heartbeat and progress
intervals; removing them to satisfy the checker leaks a timer per abandoned
stream.
Why a declaration-merge workaround does not work
Filing this after trying the obvious local patch. Inside a module:
declare global {
interface Transformer<I = unknown, O = unknown> {
cancel?: (reason?: unknown) => void | PromiseLike<void>;
}
}
This does not merge. Interface declarations must agree on their type
parameters, and lib.dom.d.ts uses <I = any, O = any> while the natural
patch uses unknown. With skipLibCheck: true the resulting TS2428 is
suppressed, so the merge silently fails and cancel stays absent. Matching
any makes it merge, but then the default type arguments on every
TransformStream in the codebase degrade to any, which trades one problem
for another.
That dead end is the reason this is filed as a lib gap rather than handled
locally.
Suggested fix
Add the member to Transformer in dom.generated.d.ts, with a callback type
next to the other three:
interface Transformer<I = any, O = any> {
flush?: TransformerFlushCallback<O>;
readableType?: undefined;
start?: TransformerStartCallback<O>;
transform?: TransformerTransformCallback<I, O>;
cancel?: TransformerCancelCallback;
writableType?: undefined;
}
type TransformerCancelCallback = (reason?: any) => void | PromiseLike<void>;
lib.webworker.d.ts has the same interface and needs the same change.
Notes
- Checked 6.0.3 and 7.0.2; both reproduce.
- Searched the issue tracker for
Transformer cancelandlib.dom TransformStream
before filing; the results were unrelated, so this does not look like a
duplicate. - TypeScript version 7 ships lib files inside the platform binary, so the
reproduction uses the CLI rather than readinglib.dom.d.tsfrom disk.
- 主要语言
- Go
- 星标
- 112k
- 派生
- 15.4k
- 平均合并
- 3 天 1 小时
- 30 天内合并 PR
- 136
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
microsoft/TypeScript 的其他 Issue
-
Won't Fix
难度 2/5 1-3 小时 新手友好度 62/100
microsoft/TypeScript#65107 · 1 条评论 ·
维护者通常 1 天内回复
-
Native API: formatDiagnosticsWithColorAndContext drops related information without a file location可能已有人在做 @timurzvural 于 1 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 75/100
microsoft/TypeScript#65087 ·
维护者通常 1 天内回复
-
TS7 LSP: documentHighlight returns nothing when the file path contains '@'可能重新可做 关联的 PR 已关闭且未合并。 未关闭Bug
难度 2/5 1-3 小时 新手友好度 78/100
microsoft/TypeScript#64758 ·
维护者通常 1 天内回复
-
Language server (tsc --lsp) exits with code 1 after `shutdown` and `exit`可能已有人在做 @rajnish-verma-22172 于 13 天前认领。 未关闭Bug
难度 2/5 1-3 小时 新手友好度 76/100
microsoft/TypeScript#64742 · 1 条评论 ·
维护者通常 1 天内回复
-
Class names `eval` and `arguments` are not reported as invalid strict mode bindings可能已有人在做 @dmety 于 26 天前认领。 未关闭Bug
难度 2/5 1-3 小时 新手友好度 68/100
microsoft/TypeScript#64661 ·
维护者通常 1 天内回复
查看 microsoft/TypeScript 的全部 Issue
相似的 Issue
-
area: frontend priority: normal
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
TestAutonomousStop_ReportsObservedState fails under host load: 1s wall-clock ceiling vs 250ms cycle未关闭type:bug
难度 2/5 1-3 小时 新手友好度 65/100
nightgauge/nightgauge#2909 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
jasonfen/terminal-space-program#842 ·
维护者通常 1 天内回复
-
enhancement good first issue
难度 2/5 1-3 小时 新手友好度 78/100
MustacheCase/zanadir#521 ·
维护者通常 1 天内回复
-
v3.1.0: spread placement groups fail — label key uses the reserved hetzner.cloud prefix可能已有人在做 @ScrimReaper 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 86/100
stubbi/karpenter-provider-hetzner#120 ·
维护者通常 4 天内回复