apifox-to-ts 工具

一个由 apifox 的接口文档生成 typescript 声明的小工具，记录一下开发过程。

仓库代码：https://github.com/JexLau/apifox-to-ts

背景

项目想要接入 typescript 开发，但维护接口的 typings 是一个繁琐且重复的过程，在观察后端提供的接口文档(基于 apifox 平台)，发现它的数据构成有一定的规律，且后端的接口规范良好，得益于在前司学到的经验，决定写一个脚本工具来对接口文档自动生成接口 typings。

当然，apifox也提供了生成typings工具，但我觉得可能存在两个缺陷：

1. 对于枚举类型的处理，在实际开发中，有些枚举书写不规范转换会报错，个人觉得还是把它处理成联合类型更好。
2. apifox 生成的代码， schema 和接口层混杂在一起，项目庞大时比较混乱，按模块生成对应的 schema 和 path 会更清晰，更容易维护。

结果

为了更清晰地感知这个工具的作用，把结果放在前面。第一个文件是service.ts文件，也就是项目中可以直接引入使用的接口文件。第二个文件是schema文件，包含了项目所有的schema。第三个文件是path文件，包含了项目所有的请求。将这三个文件复制到项目中，可直接使用。后续接口有更新，执行脚本也可一键生成，不必费力维护接口的typings。

眼尖的小伙伴当然发现了，目前项目还没有根据模块生成对应的文件，原因是因为在开发过程中，发现模块名称是中文，我不愿意根据中文生成模块，所以暂时不做。

开发过程

打开一个 apifox 项目文档，通过观察控制台的请求，发现 apifox 网页端的数据主要来源于这三个接口：

• /api/v1/shared-docs/${share_id}/data-schemas 用来请求schemas(抽象集合)
• /api/v1/shared-docs/${share_id}/http-api-tree 用来请求接口所有模块
• /api/v1/shared-docs/${share_id}/http-apis/${api_id} 用来请求某一接口的具体构成(api_id是通过上一个接口http-api-tree拿到的)

share_id 为项目分享生成的 id

在日常开发中，我们知道一个请求主要有这两部分：请求参数Request+请求返回值Response，请求Path。第一部分可以抽象地看成是Schema(抽象集合)，第二部分就是Path，工具函数需要做的就是解析这两部分。

1. 解析schema

上一步我们知道 data-schemas 这个接口可以拿到项目中所有 schemas，我放个具体的截图感受一下。左边是整体