TypeScript应用中管理生成的GraphQL Schema的最佳实践咨询

原方案1的合规改造方向 #

你最初的思路是合理的，DevOps团队反对的核心原因是你把Schema拉取逻辑放在了Docker构建阶段：该阶段要求镜像构建过程可复现、不依赖任何外部运行中的服务，一旦换个无可用Hasura的构建环境，镜像就会构建失败，不符合CI/CD的通用规范，并非服务之间不能存在依赖，只是依赖放错了执行阶段。

有两种合规的改造路径：

路径1：调整CI流水线步骤 #

• CI任务先启动临时Hasura容器，加载当前版本的所有元数据（表结构、权限规则、自定义逻辑等）直到完全就绪
• 执行Schema拉取和TS类型生成脚本，将生成的文件存入Express的构建上下文
• 执行Express的Docker构建，此时构建上下文已包含所需类型文件，无需依赖任何外部服务
• 销毁临时Hasura容器，推进后续部署流程

路径2：将Schema拉取逻辑移到容器启动阶段 #

• Docker构建阶段仅编译Express的基础代码，不涉及任何Schema相关操作
• 容器镜像内内置轻量等待脚本，启动命令调整为：
  ./wait-for-it hasura:8080 -- node ./pull-schema-and-start.js
• 启动时先等待Hasura服务就绪，拉取Schema生成类型文件后再启动Express服务
  该方案完全符合Docker规范，运行阶段的服务依赖是合理的，部署时本身就需要保障Hasura服务的可用性。

原方案2的可落地实现 #

如果暂时要采用跳过类型校验的方案，可以通过修改TS配置实现构建不失败：

• 修改tsconfig.json，添加"noEmitOnError": false配置，即使TS抛出类型错误也会正常输出编译后的JS文件
• 如果仅需要忽略GraphQL相关的类型报错，可以在对应查询语句上方添加// @ts-ignore单行注释，或者在GraphQL Code Generator的配置文件中添加ignoreNoDocuments: true等规则定向忽略
  该方案牺牲了类型校验的安全性，仅建议临时使用。

原方案3的优化建议 #

如果团队暂时保留提交Schema到Git的方案，可添加CI校验规则降低维护成本：

• 每个PR发起时自动拉取对应版本Hasura的Schema生成文件，和PR中提交的Schema文件对比，不一致则阻断合并
• 约定Schema文件仅由CI自动生成提交，禁止本地手动修改，可大幅降低冲突概率

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