背景
新进了一家初创公司，啥也没有，所有东西都得从头开始进行基建。 我们平时和后端对接接口的时候都需要根据后端提供的接口文档来再写一遍调用接口的方法，十分的繁琐和无意义，对技术的提高也没有任何帮助。
感谢工作的第一家公司，技术大佬写了一个根据OpenAPI3规范生成前端ts模型和接口调用方法的脚本，十分便捷，后端提供一份符合OpenAPI3规范的Swagger JSON就可以一键生成，使得平时开发工作从繁琐的类型定义和模型定义以及接口方法书写重复劳动中解脱出来，类型即文档，堪称anyscript到typescript的蜕变哈，给我留下了深刻的印象。
进到新公司后，需要从头开始基建，萌生了自己写一个的想法。
使用效果
这里先放一个使用效果介绍。
模型和接口方法都是生成的，不需要自己写，节省大量重复劳动：
调研
由于还有业务需要写，所以工具类不能放太多时间， 我就调研了市面上根据OpenAPI规范生成ts代码的库想拿来适配一下。查了一些库，不太合适，有的太庞大了，不方便修改，想起来Ant Design Pro貌似自带了生成API的功能，就去翻来查看了一下，发现Ant Design Pro引用了一个名为@umijs/plugin-openapi的库。
进入这个库，找到源码(openapi2typescript)，发现很符合我的需求，构思和我差不多，核心代码也不多，fork到本地，测试生成代码，发现生成的代码也很符合我的需求，只需要调整一下。
确定调整范围
观察这个库生成的代码和文件：
- 类型
- 接口代码
结构和生成的代码基本符合需求，但是还需要根据我自己的想法做一些修改
大概改了以下几点：
- 生成可以实例化的 class，而非 interface
- 使用类和静态方法重新组织代码结构，而非分散每一个接口
- 将接口重复类型改为泛型
- 对 API FOX 进行了适配 （java 等可以不写 swagger 注解 直接写注释 使用 api fox 生成文档和 json 文件）
一、生成可以实例化的 class，而非 interface
一开始团队使用ts生成脚本之后，有了类型提示很舒服，但是因为项目实际业务中需要定义大量的对象变量并实例化，每次类型有这个属性，但是一引用就报错是空值，每次手动实例化都占用非常大的篇幅，而且这个报错经常出现，十分痛苦。
技术大佬知道后思绪良久，妙手一出把原来生成的interface改为了class。从此实例化对象直接new一个就好了，快、准、狠，爽！
原来爽到的，现在咱也要！这一步的调整比较简单，因为原作者使用了一个.njk的模板文件，直接弄一个适配的模板就好了，下面是修改后重新生成的模型，改为了类以及进行了初始化。
二、使用类和静态方法重新组织代码结构
原作者生成的接口方法比较散乱，调整为使用类和静态方法组织代码，也方便使用装饰器对代码进行权限校验等各种扩展AOP处理，代码集合使用起来也比较方便。
三、将接口重复类型改为泛型
这是一些细节上的优化了，改为更符合自己的使用习惯，也去掉一些重复的类型，更合理一些。还有枚举上的一些修改。
四、对 API FOX 进行了适配
之所以有这条是因为我们的java后端不喜欢写swagger注解，用APIFOX提供文档，喜欢直接写注释，我也喜欢这种对代码减少侵入的形式，一大堆swagger注解对比C#的优雅写法来说实在是太丑了。
这里根据APIFOX导出的JSON进行了定制性的优化适配。
因为需要适配APIFOX，业务又着急，所以有些地方赶速度就没预留太通用，现在不知道其他地方好不好用了。 APIFOX选择导出数据，选择OpenAPI3.0规范使用。
最后
改好后我重新发了一个包，可以体验一下
shell
pnpm add openapi-genuu -D
- 使用
npm： www.npmjs.com/package/ope...
修改后的源码： github.com/sharebraver...
原来的库：github.com/chenshuai21...
END