Manage CODEOWNERS programmatically (and regenerate it)

[mcmire]

Explanation

At the time of writing we have 97 (!!) packages in this monorepo, which are owned by various teams across MetaMask. However, managing codeownership via the CODEOWNERS file is tedious and error-prone.

We do use Yarn constraints to ensure that each package is configured in CODEOWNERS correctly, so that helps. However, in a future commit, we would like to update the set of per-package files that are owned by Core Platform to include more than just package.json and CHANGELOG. at the moment, we need to do that manually — Yarn constraints won't allow us to automatically apply those updates — and it would be painful.

To address this problem, this commit redefines CODEOWNERS as a TypeScript file (codeowners.ts in the root) and adds a script to generate CODEOWNERS from this file. The script also comes with a check command which is plugged into the lint pipeline to ensure that CODEOWNERS is always up to date.

The primary "feature" of codeowners.ts is that it contains a configuration object which maps of teams to packages that are owned by those teams (along with some other metadata). Ideally, when a new package is added, all a team needs to do is update this map and then the appropriate codeowner rules will be automatically added to support that package.

That said, to ensure minimal changes between the current version of CODEOWNERS and the new version in this PR, some compromises needed to be made, and as a result, codeowners.ts is not as dynamic or simple as it could be. In the future, we plan on making further changes to make codeowners.ts easier to maintain.

References

To merge #8384, I had to enable admin powers to bypass codeowner requirements. This is because tsconfig files are not co-owned by Core Platform. We could of course change CODEOWNERS to do this, but what if we want to add other kinds of files in the future? This file is already somewhat difficult to maintain and we don't want to make it worse. This PR came out of that observation.

Manual testing

• Run yarn codeowners:check. It should not print any output, and should exit with 0.
• Run yarn codeowners:generate. It should also not print any output, it should not change .github/CODEOWNERS, and should exit with 0.
• Open codeowners.ts and add @MetaMask/core-platform to the list of teams for account-tree-controller.
• Run yarn codeowners:check. It should print an error.
• Run yarn codeowners:generate. .github/CODEOWNERS should change (the list of owners for account-tree-controller should include @MetaMask/core-platform`).
• Undo the changes to .github/CODEOWNERS.
• Open codeowners.ts and remove initializationPath from address-book-controller.
• Run yarn codeowners:check. It should print an error.
• Run yarn codeowners:generate. .github/CODEOWNERS should change (address-book-controller should be removed from the "Initialization" section).

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

Note

Low Risk
Repo tooling and generated ownership metadata only; no runtime product or security logic changes.

Overview
CODEOWNERS is now generated from a root codeowners.ts config instead of being edited by hand. Teams update package ownership (and optional wallet initializationPath metadata) in one place; the generator builds team sections, joint ownership, initialization paths, and release package.json / CHANGELOG.md rules with aligned column padding.

New yarn codeowners:generate and yarn codeowners:check (wired into lint, lint:fix, and the CI lint matrix) keep .github/CODEOWNERS in sync. tsconfig.json includes codeowners.ts for typechecking.

^{Reviewed by Cursor Bugbot for commit 2426a9b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[mcmire]

As I alluded to in the PR description, this file is way longer than it should be, mainly because I wanted the diff for CODEOWNERS to be relatively easy to read. In the future we should be able to generate most of this purely from PACKAGES (with a few exceptions). For instance, this would be the bulk of the new version:

function buildPackageSections() {
  return PACKAGES_BY_GROUP.flatMap((group) => {
    return [
      [`### ${group.name}`],
      group.packages.flatMap((package) => {
        return [
          {
            pattern: package.workspacePath,
            owners: group.teams,
          },
          ...(
            package.isPartOfWalletLibrary
              ? {
                pattern: `/packages/wallet/src/initialization/instances/${package.directoryName}`,
                owners: group.teams,
              }
              : {},
          ),
          {
            pattern: `${package.workspacePath}/package.json`,
            owners: [CORE_PLATFORM_TEAM]
          },
          {
            pattern: `${package.workspacePath}/CHANGELOG.json`,
            owners: [CORE_PLATFORM_TEAM]
          }
        ]
      })
    ]
  })
}

[Mrtenz]

mainly because I wanted the diff for CODEOWNERS to be relatively easy to read

Is this the reason why a lot of stuff here is duplicated? Fine with me to resolve in a follow-up if you think that's easier.

[mcmire]

Yes, I plan on posting another PR that simplifies this file.

[mcmire]

Using a TypeScript file to generate CODEOWNERS also lets us automatically check this in the future. That should allow us to remove this comment.

[mcmire]

To read this diff, you'll probably want to turn off whitespace. (I could have coded whitespace settings into codeowners.ts but I didn't want to make that file worse than it already was.)

[mcmire]

For some reason accounts-controller/CHANGELOG.md was listed further down than it should have been.

[mcmire]

The files for config-registry-controller were listed in the wrong order.

[Mrtenz]

Maybe this should be a separate JSON or YAML file in .github, like .github/CODEOWNERS.yml?

[mcmire]

It was my intent that codeowners.ts was the configuration file, just a programmatic version of it (similar to eslint.config.mjs). My concern with adding .github/CODEOWNERS.yml is that we'd essentially have two configuration files.

As mentioned before this file will be a lot simpler in the future, so it will be primarily the PACKAGES list along with some code to generate each line in CODEOWNERS. That said, do you think any of this code should be in manage-codeowners.ts?

[Mrtenz]

I think eventually this file should be just the PACKAGES list, with the code to generate the CODEOWNERS file in manage-codeowners.ts? But my thinking was at that point the PACKAGES could just as well be a JSON or YAML file (YAML for comment support and better readability). Don't think having two configuration files is a problem as long as the GitHub one is clearly marked as auto-generated, with the YAML one essentially becoming the real config file.

[mcmire]

Gotcha. I did consider making a JSON/YAML file initially but thought that if any team needed to make an exception to the existing logic, they could do so easily if the file were a TypeScript file instead of JSON/YAML. But maybe I can allow for some exceptions. I'll play around with that in the followup PR.

[Mrtenz]

Looks good to me!