Inquirer.js 中 instanceof 检查失效问题的分析与解决

问题背景

在使用 Inquirer.js 这个流行的 Node.js 交互式命令行工具库时，开发者经常需要处理用户通过 Ctrl+C 触发的退出操作。Inquirer.js 提供了一个专门的 ExitPromptError 错误类来表示这种情况。然而，许多开发者发现使用 instanceof 操作符检查错误类型时总是返回 false，导致无法正确识别这类错误。

问题本质

这个问题的根源在于 JavaScript 模块系统和现代构建工具的工作方式。当开发者从 @inquirer/core 包导入 ExitPromptError 类时，构建工具（如 tsup、webpack 等）可能会将这个类重新打包，而不是直接引用原始模块中的类定义。

这就导致了两个问题：

1. 应用代码中的 ExitPromptError 和 Inquirer 内部使用的 ExitPromptError 实际上是两个不同的类定义
2. 虽然它们有相同的名称和结构，但由于来自不同的模块实例，instanceof 检查会失败

解决方案

1. 显式安装核心包

对于使用 tsup 等构建工具的项目，最简单的解决方案是显式安装 @inquirer/core 包：

npm install @inquirer/core

这可以确保构建工具能够正确识别并外部化这个依赖，而不是重新打包它。

2. 使用错误名称检查（推荐）

更健壮的解决方案是避免使用 instanceof，转而检查错误的 name 属性：

// 替代 error instanceof ExitPromptError
if (error.name === 'ExitPromptError') {
  // 处理退出提示错误
}

Inquirer.js 的维护者已经承诺会在未来的版本中为所有错误类添加 name 属性，使这种检查方式更加可靠。

深入理解

为什么 instanceof 不可靠

instanceof 操作符在 JavaScript 中检查的是对象的原型链是否包含特定构造函数的 prototype 属性。当类定义被不同模块实例化时，即使代码完全相同，它们的 prototype 也是不同的，导致 instanceof 检查失败。

构建工具的影响

现代构建工具为了提高性能，常常会重新打包依赖项。这种行为在大多数情况下是优化的，但在需要严格类型检查的场景下会导致问题。特别是当：

1. 依赖项没有被正确列为外部依赖
2. 构建配置没有正确处理子依赖项
3. 使用了不同的模块系统（CJS/ESM）

最佳实践

1. 避免依赖 instanceof：在跨模块边界时，instanceof 检查不可靠
2. 使用鸭子类型：检查对象是否具有预期的属性或方法
3. 使用符号属性：可以定义跨模块唯一的符号作为类型标识
4. 明确错误处理策略：为不同的错误类型定义清晰的识别和处理逻辑

总结

在 Inquirer.js 或其他类似库的开发中，处理特定类型的错误时，instanceof 检查可能会因为模块系统和构建工具的行为而失效。采用基于属性检查的替代方案不仅解决了当前问题，还能使代码更加健壮和可维护。理解 JavaScript 模块系统的工作原理对于诊断这类问题至关重要。