如何在微服务代码库间共享TypeScript类型与JSON Schema并保持同步？

在多仓库场景下避免重复定义共享类型、防止不同步，业内有几种经过验证的主流方案，各有适用场景和偏好：

1. 独立的类型定义包（最普遍的工业级方案） #

将所有共享数据类型单独抽离成一个独立的包（比如npm包、Maven模块、PyPI包等），发布到私有或公共包管理仓库，各个业务仓库通过依赖声明引入这个包。

• 操作示例：在TypeScript项目中，创建@your-org/shared-types包，定义User、Order等类型，业务仓库执行pnpm add @your-org/shared-types引入，直接使用import { User } from '@your-org/shared-types'。
• 核心优势：统一维护入口，版本化管理（比如语义化版本），更新时通过包版本升级同步，能精准控制各仓库的类型更新节奏；类型变更可做兼容性校验（比如TypeScript的tsc检查）。
• 业内偏好：大厂、中大型团队的首选方案，尤其是业务线独立但依赖通用类型的场景，能最大化保证类型一致性，同时兼顾各仓库的独立性。

2. Monorepo（单仓库）模式 #

把所有相关业务代码和共享类型放在同一个Git仓库中，共享类型放在仓库根目录的公共目录（比如packages/shared-types），各个子项目直接通过相对路径或工作区依赖引用。

• 操作示例：用pnpm Workspace，在pnpm-workspace.yaml中声明共享包，业务项目的package.json中依赖写"@your-org/shared-types": "workspace:*"。
• 核心优势：无需额外的包发布流程，修改共享类型后所有子项目实时生效，调试成本低；适合快速迭代的场景。
• 业内偏好：小型团队、前端项目或需要频繁迭代类型的场景，现在很多前端团队倾向于用pnpm Workspace、Nx这类轻量或功能完善的Monorepo工具。

3. 基于单一数据源的代码生成 #

以统一的数据源（比如Protobuf、GraphQL Schema、OpenAPI规范）作为类型的唯一来源，通过代码生成工具自动生成各语言/仓库的类型定义。

• 操作示例：用Protobuf定义user.proto，通过protoc工具生成TypeScript、Java、Go等多语言的类型文件；或基于GraphQL Schema，用@graphql-codegen/cli生成前端组件的类型。
• 核心优势：一次定义多语言复用，从根源避免类型不一致；适合跨语言微服务、API驱动的项目。
• 业内偏好：跨语言项目、微服务架构的首选，尤其是后端多语言协作的场景，Protobuf几乎是行业标准。

4. Git子模块/子树（不推荐频繁更新场景） #

将共享类型仓库作为子模块嵌入到各个业务仓库中，通过Git管理版本。

• 核心问题：子模块的使用成本高，新手容易出现版本同步错误；更新类型需要手动在每个仓库拉取子模块最新版本，难以规模化维护。
• 业内偏好：仅适用于 legacy 项目或类型极少变更的场景，现在已经逐渐被独立包或Monorepo替代。

5. 本地符号链接（仅作为开发辅助） #

本地开发时，用npm link、yarn link或pnpm的工作区链接，将共享类型目录直接链接到业务仓库的node_modules中。

• 核心作用：仅解决本地开发时的实时调试问题，生产环境仍需依赖独立包或Monorepo方案，不能解决线上同步问题。
• 业内偏好：作为独立类型包开发时的辅助手段，配合正式方案使用。

业内共识总结 #

1. 优先选择独立类型包或Monorepo，根据团队规模和项目复杂度决策：团队规模大、业务独立选独立包；团队小、迭代快选Monorepo。
2. 跨语言场景必选代码生成（Protobuf/GraphQL/OpenAPI）。
3. 尽量避免使用Git子模块，除非是特殊历史遗留场景。

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