GraphQL-Request 项目中的 CLI 功能分离探讨

GraphQL-Request 是一个轻量级的 GraphQL 客户端库，在 7.0.0 版本中引入了 CLI 功能，用于生成类型化的客户端代码。这一变化引发了社区关于功能分离的讨论，特别是关于如何平衡核心功能与附加工具之间的关系。

在 7.0.0 版本之前，GraphQL-Request 主要专注于提供简洁高效的 GraphQL 请求功能。新加入的 CLI 工具虽然为某些开发者带来了便利，但也带来了显著的依赖体积增加。这些新增依赖包括 dprint、@dprint/*、@molt/command 和 zod 等，总计增加了超过 20MB 的空间占用，在某些使用场景下甚至会使 Docker 镜像大小增加 50-100%。

从技术架构角度看，GraphQL 客户端核心功能与代码生成工具确实是两个相对独立的关注点。核心客户端负责运行时请求处理，而 CLI 工具则属于开发时辅助功能。将它们分离可以带来几个明显优势：

1. 减小核心包体积：对于只需要基本 GraphQL 请求功能的用户，可以避免不必要的依赖
2. 独立演进：两个功能可以按照各自的节奏进行开发和版本迭代
3. 更灵活的部署：生产环境可以只安装运行时依赖，开发环境再选择性添加 CLI 工具

社区提出的解决方案主要有两种思路：一是将 CLI 功能完全分离到独立的 npm 包中；二是将部分依赖改为可选依赖（peer dependencies）。项目维护者目前倾向于后者作为短期解决方案，特别是将 dprint 改为可选依赖，这能立即解决大部分体积问题。

对于长期规划，项目可能会在迁移到 graffle 命名空间时，将 CLI 功能完全分离到 graffle-cli 包中。这种架构演进需要仔细规划，包括考虑包命名策略、版本同步和迁移路径等问题。

从工程实践角度看，这种功能分离反映了现代 JavaScript 生态中一个常见的设计考量：如何在提供丰富功能的同时保持核心的轻量化。类似的设计模式在其他流行库中也能看到，如 Babel 的核心与插件体系、Webpack 的核心与 loader 机制等。

对于开发者来说，理解这种架构决策有助于做出更明智的技术选型。如果项目只需要基本的 GraphQL 请求功能，可以考虑继续使用 6.x 版本；如果需要代码生成工具，则可以接受 7.x 版本的额外依赖；未来则可能需要在核心包和 CLI 包之间做出明确选择。