背景
新进了一家初创公司，啥也没有，一切东西都得从头开始进行基建。 咱们平常和后端对接接口的时候都需求依据后端供给的接口文档来再写一遍调用接口的办法，非常的繁琐和无意义，对技能的进步也没有任何协助。
感谢作业的第一家公司，技能大佬写了一个依据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标准运用。
最后
改好后我重新发了一个包，能够体验一下
pnpm add openapi-genuu -D
- 运用
npm： www.npmjs.com/package/ope…
修正后的源码： github.com/sharebraver…
END
