从Node迁移TypeScript时遇到eslint显式模块边界类型规则报错疑问

你遇到的报错不是TS能力不足，也不是规则在故意找事——@typescript-eslint/explicit-module-boundary-types的设计目标非常明确：所有跨模块导出的函数，必须显式标注返回类型，不能依赖TS的隐式推断。
这个规则要解决的问题是：如果导出的函数完全靠TS自动推断返回类型，那么你内部代码的任何无意改动（比如重构时把返回的publish改成send、不小心调整了函数参数顺序）都会悄无声息地改变对外的类型契约，把类型错误推到所有下游依赖的调用位置，排查起来非常麻烦。而显式标注返回类型相当于给模块加了一道防火墙：只要内部实现和对外约定的形状不一致，TS会直接在当前模块报错，不会把问题漏出去。

手写返回接口的写法是否合理？ #

你现在手写返回接口的思路是对的，觉得麻烦只是因为大概率会不小心重复抄写参数定义，导致同步修改的负担。只要调整一下类型的引用结构，完全可以做到零重复维护。
很多人写返回接口的时候会把参数形状硬编码进去，比如：

// 冗余写法：把publish的参数形状抄到了返回接口里
interface SNSReturnInterface {
  publish: ({ message, topicArn }: { message: any; topicArn: string }) => Promise<void>;
}

这种写法才会导致你以后给publish加个参数，就要同时改PublishInterface和SNSReturnInterface两个地方。正确的做法是把所有可变的参数逻辑集中到一个公共接口里，返回接口只做类型引用，不重复定义细节：

// 所有可变的参数、属性定义只维护这一处
interface PublishInterface {
  message: any;
  topicArn: string;
  // 以后新增参数，只需要改这里
  messageAttributes?: Record<string, any>;
}

// 返回接口只引用公共类型，不需要跟着调整
interface SNSReturnInterface {
  publish: (args: PublishInterface) => Promise<void>;
}

这种结构下，不管你以后给publish加多少参数、调整多少参数类型，只要修改PublishInterface的定义，返回接口、内部的publish函数实现都会自动同步类型，完全没有重复修改的负担。

更省事的优化选项 #

如果你觉得单独抽一个返回接口太麻烦，也可以直接在函数定义上写内联的返回类型，效果完全一样：

const sns = ({ config, logger }: SNSInterface): { publish: (args: PublishInterface) => Promise<void> } => {
  // 原有实现逻辑完全不需要改动
}

这种写法适合返回结构简单的场景，不需要额外定义接口名。
当然，如果你实在不想写返回类型，也可以在不全局关闭规则的前提下，给规则配置allowedNames字段，把sns这类工厂函数加进白名单，就可以跳过检查。但这种方式会失去规则对API契约的保护能力，属于下策，不建议优先使用。

从长期维护的角度看，只要你把公共参数抽成独立接口，需要写的类型代码非常少，换来的是模块边界的稳定性——尤其是你这种从Node迁移到TS的项目，本来就是要靠显式的类型约束减少后续重构的问题，完全没必要为了省几行类型代码放弃这层保护。

内容的提问来源于stack exchange，提问作者Sam Chung