前端monorepo大仓权限设计的思考与实现

一、背景

前端 monorepo 在试行大仓研发流程过程中，已经包含了多个业务域的应用、共享组件库、工具函数等多种静态资源，在实现包括代码共享、依赖管理的便捷性以及更好的团队协作的时候，也面临大仓代码文件权限的问题。如何让不同业务域的研发能够顺畅的在大仓模式下开发，离不开有效的权限管理方法。好的权限管理方法能够确保研发同学轻松找到和理解项目的不同部分，而不受混乱或不必要的复杂性的影响，并且也应该允许研发同学合作并同时工作，同时也要确保代码合并的更改经过代码审查，以维护代码的质量和稳定性。本文通过实践过程中遇到的一些问题以及逐步沉淀下来的最佳实践，来阐述下前端大仓 monorepo 在权限这块是如何思考以及设计的。

二、前期调研

在做大仓权限设计的时候，前期做了很多的调研，也参考了国内和国外的一些技术文章，总结起来主要是基于以下三点的设计思路去实现：

• 文件系统的自研，能够做到文件读写权限的完全控制：对于文件系统的自研，国外的最佳实践不外乎是 Google 和 Meta，他们都是大仓实践的典范。对于文件系统的权限控制，有一套自研的文件系统，能够对核心代码和配置文件做到读写权限控制。在 Google 发表的一篇论文《Why Google stores billions of lines of code in a single repository》中也有提到：

Since Google’s source code is one of the company’s most important assets, security features are a key consideration in Piper’s design. Piper supports file-level access control lists. Most of the repository is visible to all Piper users;d however, important configuration files or files including businesscritical algorithms can be more tightly controlled. In addition, read and write access to files in Piper is logged. If sensitive data is accidentally committed to Piper, the file in question can be purged. The read logs allow administrators to determine if anyone accessed the problematic file before it was removed.

大致的意思是 Google 内部自研了 Piper，能够支持基于文件级别的访问控制列表，大多数仓库对所有 Piper 用户可见，但是重要的配置文件或包含业务关键算法的文件可以进行更严格的控制，并且对 Piper 中的文件的读写访问都会被记录。

• 基于 Git 提供的钩子函数，能做到文件写权限的控制：Git 本身是一个分布式文件系统，其提供了代码研发流程中的各种钩子函数，在不同的钩子函数里面对文件的修改做校验，可以做到代码文件写权限的控制，但是做不到代码文件的读权限控制；

• 基于 Gitlab 的能力，对文件目录权限做控制：Gitlab 开始引入了“Protected Environments”的概念，即允许为具体的文件或目录设置权限，并指定哪些用户或用户组拥有文件的“Maintainer”权限，以便管理文件的更改和合并请求，可以用于更细粒度的文件级别权限控制。当然此种方法也只能做到代码文件写权限的控制，做不到代码文件的读权限控制。

从上面的三种调研实现来看，如果要完全做到文件系统的读写权限控制，势必需要自研一套适合研发流程及业务体系的文件系统，这种实现成本会很大，且基于实际的应用场景去考虑，也不是很有必要。所以本文主要围绕基于 Git 提供的钩子函数和基于 Gitlab 的能力来阐述过程中是如何实践的。

三、设计实现

在前端 monorepo 实践过程中，对于权限模块的设计如果考虑不好的话，会带来很不好的研发体验，同