Question 1

如何修复 tsgo LSP 服务器关闭时出现的 panic“assignment to entry in nil map”？

Accepted Answer

这是原生 TypeScript 编译器（tsgo / typescript-go，typescript@7.0.2）中的一个关闭竞态。当 LSP 客户端未声明支持动态文件监视注册时，服务端的内部监视器（`internal/lsp/lspwatcher`）会在安装监视订阅期间释放其互斥锁；此时并发的 `Close` 会将 `w.watches = nil`，随后安装完成后的追加操作便以 `assignment to entry in nil map` 触发 panic，导致 `tsgo --lsp --stdio` 以状态码 2 退出。修复方法：升级到包含 PR microsoft/typescript-go#4845 的 `@typescript/native-preview`（tsgo）构建版本，该 PR 会在发布订阅之前于锁内重新检查 `closed` 标志，并返回 `lspwatcher: closed` 错误而非 panic。如果被锁定在受影响的构建版本，变通方法是：在 LSP 客户端中启用动态文件监视注册（`workspace.didChangeWatchedFiles.dynamicRegistration: true`），使服务端跳过其内部监视器路径。

Question 2

如何修复未导出的递归类型别名在 TypeScript 声明文件中被内联并变成 any 的问题？

Accepted Answer

当导出的值使用了未导出的递归类型时，如果启用了 declaration: true，就会出现这种情况。声明生成器无法引用私有类型名，因此它会内联该递归，直到达到深度限制，并替换为 any。通过从声明该类型的模块中导出递归类型别名来修复： // utils.ts export type Recursive = T extends Array ? Recursive : T; export const f = (): Recursive => null!; 然后使用 npx tsc -p tsconfig.json 重新构建。生成的 .d.ts 现在可以引用 Recursive，而不是将其展开。如果该类型必须保持私有，请将其从导出的 API 中移除，或为导出的声明提供显式的公共返回类型。typescript-go PR #4507 中也进行了编译器修复，改为报告声明错误，而不是静默生成 any。

Question 3

如何修复当局部变量遮蔽某个导出时，TypeScript CommonJS 输出在函数内的循环中添加 exports.x 的问题？

Accepted Answer

这是 tsgo CommonJS 转换器中的一个回归：一个名称与某个导出名称匹配的块级作用域循环变量，会错误地收到 exports.name = name 赋值。它可在 tsgo 7.0/dev 构建中复现，而 TypeScript 6.0.3 会生成正确代码。

变通方法：

1. 重命名循环局部变量，使其不遮蔽该导出：
export function f(xs: number[]) {
  for (const x of xs) {
    const localMount = x;
    console.log(localMount);
  }
}
function mount() {}
export { mount };

2. 使用稳定的基于 JavaScript 的编译器，而不是受影响的 tsgo 构建：
npm install -D typescript@6.0.3
npx tsc

3. 如果在本地构建 tsgo，请修补 internal/transformers/moduletransforms/commonjsmodule.go。对于非顶层循环，使用常规 visitor 访问循环体，而不是 topLevelNestedVisitor：
- tx.EmitContext().VisitIterationBody(node.Statement, tx.topLevelNestedVisitor)
+ tx.EmitContext().VisitIterationBody(node.Statement, tx.Visitor())

在 visitForInOrOfStatement 中应用等效更改；顶层循环必须继续使用顶层嵌套 visitor。修复已在相关 pull request 中跟踪。

Question 4

为什么在修改 node_modules 中某个 .d.ts 文件里的 'declare global' 类型后，tsc --incremental 会漏报错误？

Accepted Answer

这是 TypeScript 7.0.x 中的一个已知回归问题（同样存在于 5.6.1-rc；在 6.0.3 中工作正常）：当某个包的声明文件（通过 types 加载，而非导入）中的 declare global 代码块发生更改时，增量构建会保留过时的诊断信息，导致增量运行不报告任何错误，而干净的 tsc 运行则会报告这些错误（例如 TS2345）。修复方法：升级到 TypeScript 7.1 或更高版本（已确认在 7.1 nightly 中修复）。受影响版本的临时解决方法：在每次运行前删除 .tsbuildinfo 文件（例如 rm tsconfig.tsbuildinfo），或者在不使用 --incremental 的情况下运行 tsc --noEmit，以强制进行完整的重新检查。

Question 5

为什么 TypeScript 接受 import defer "./a.js" 并将其作为普通的 eager import 输出？

Accepted Answer

裸的 import defer "./a.js" 是无效的：延迟导入提案要求一个命名空间绑定。TypeScript 错误地接受它并丢弃 defer，生成 import "./a.js"，这会立即求值该模块。

要进行延迟求值，请使用命名空间导入：

import defer * as ns from "./a.js";

如果你有意要仅副作用的导入，请改用常规的立即导入：

import "./a.js";

受影响的版本包括 TypeScript 5.9.3 和 7.1.0-dev.20261004.1。

TypeScript

核心功能

避坑指南

适用场景

标签

快速上手

相似推荐