CEL-Go项目中common/ast包的Bazel可见性问题解析

在Google开发的CEL-Go项目中，common/ast包提供了一个用于遍历和操作抽象语法树(AST)的重要接口ast.Visitor。这个包本应是一个公共API，但在Bazel构建系统中却被意外标记为私有可见性，导致开发者在使用时遇到了构建问题。

问题背景

CEL-Go是一个用于处理通用表达式语言(Common Expression Language)的Go实现。common/ast包作为项目核心组件之一，提供了AST遍历和操作的基础设施。开发者可以通过实现ast.Visitor接口来对解析后的表达式进行自定义验证和处理。

虽然该包在标准Go工具链下可以正常使用，但在Bazel构建系统中却遇到了可见性问题。问题的根源在于common/ast目录下的BUILD.bazel文件将默认可见性设置为仅限子包(subpackages)，这限制了外部项目对该包的引用。

技术细节分析

Bazel作为一种强调显式依赖和严格可见性控制的构建系统，要求每个目标(target)明确声明其可见性范围。在CEL-Go项目中，common/ast包的BUILD.bazel文件最初设置为仅对项目内部可见，这可能是出于以下考虑：

1. 开发初期保护内部API不被外部依赖
2. 防止在接口稳定前被广泛使用
3. 遵循最小权限原则

然而，随着项目成熟，ast.Visitor接口已经成为一个稳定且有用的公共API，这种限制反而成为了开发者的障碍。

解决方案演进

在官方修复前，开发者发现了两种临时解决方案：

1. 强制重新生成Bazel构建文件：通过配置go_repository规则，利用大小写不匹配的技巧使Gazelle忽略原有构建文件并生成新的公开可见目标。

2. 使用自动生成的别名：依赖Bazel工具自动生成的:go_default_library目标，该目标默认具有公开可见性。

这两种方法虽然可行，但都属于临时解决方案，不够优雅且可能带来维护问题。最终，项目维护者确认该API已稳定可用，并正式将包可见性改为公开，从根本上解决了这个问题。

对开发者的启示

这个案例展示了几个重要的工程实践：

1. API可见性设计：在开发初期限制API可见性是合理的，但随着API成熟应及时开放。

2. 构建系统兼容性：项目应确保在不同构建系统下行为一致，避免Go工具链和Bazel之间的差异。

3. 开发者体验：良好的错误信息和文档可以帮助开发者更快理解和解决问题。

对于使用CEL-Go的开发者来说，现在可以放心地在Bazel项目中直接引用common/ast包，无需再使用任何变通方案。这一变更体现了开源项目对开发者需求的积极响应，也展示了API设计随项目演进的典型过程。