Permission Design for Front-end Monorepo in Large-Scale Development

The article describes a practical permission management solution for a front‑end monorepo used in a large‑scale development workflow. It outlines the background, research, design, and extensions of the permission system.

Background : In a monorepo containing multiple business domains, shared components, and utilities, developers face challenges in controlling file‑level access while maintaining collaboration and code‑review quality.

Pre‑research : The team investigated three approaches: (1) building a custom file system with full read/write control (as used by Google and Meta), (2) leveraging Git hook functions for write‑permission checks, and (3) using GitLab’s Protected Environments to assign per‑directory permissions. The final solution combines Git hooks and GitLab’s protected branch/environment features.

Design Implementation :

1. Branch Model Definition : A clear directory hierarchy is defined – {"Apps": {"_Share": "shared deps", "Abroad-Crm-Micro": "app name", "...": "future apps"}, "Components": "shared UI", "Packages": {"Components": "platform UI", "Hooks": "platform hooks", "...": "custom extensions"}} . This semantic naming helps developers locate files quickly.

2. Role Permission Allocation : The standard GitLab roles are used – Owner (TL), Maintainer (TL/PM), and Developer (regular developers). Owners have full control, Maintainers can manage branches and merge requests, while Developers can create feature branches but cannot directly merge into protected release or hotfix branches.

3. Directory Permission Configuration : Before GitLab supported directory permissions, custom Git hooks validated file changes against a mapping of directories to owners. After support was added, the UI allows setting file‑owner permissions per path, enforcing review by the appropriate owner during MR.

4. Workflow Permission Control : The process follows Commit → Push → Create MR → CodeReview → Merge . Pre‑commit and pre‑push hooks verify that only authorized owners can modify core files. Protected branches (release, hotfix, master) prevent direct local merges, ensuring all changes go through MR & CodeReview.

Extension Ideas :

• Access Control List (ACL) : Fine‑grained directory ACLs could restrict sensitive files, though the team deemed the cost high.

• File Access Logging : When a file is opened, a log is sent to a server. An example VSCode extension implementation is shown below.

VSCode settings to hide a directory:

{
  "files.exclude": {
    "**/scripts": true
  }
}

Shell command to hide a directory on macOS:

chflags hidden **/scripts

TypeScript snippet for a VSCode file‑access monitor:

export function monitorPermissionOfTargetFile(targetFilePath: string, repoRootPath: string) {
  const targetFileFullPath = repoRootPath + targetFilePath;
  // callback for any opened file in the workspace
  vscode.workspace.onDidOpenTextDocument(textDocument => {
    // get the opened file path
    const filePath = textDocument.uri.fsPath;
    if (filePath === targetFileFullPath) {
      // add log‑sending logic here
    }
  });
}

The article concludes that the combined use of branch protection, Git hooks, and role‑based permissions effectively mitigates risks such as inconsistent builds and unauthorized file changes, while acknowledging that full read‑permission control remains an open challenge.