Ensure refs in tsconfig files are synced with internal deps - #8384
Conversation
2929cc5 to
6cb4611
Compare
| "path": "../messenger/tsconfig.build.json" | ||
| }, | ||
| { | ||
| "path": "../controller-utils/tsconfig.build.json" |
There was a problem hiding this comment.
This dependency is present in devDependencies but was missing as a reference.
| "path": "../messenger" | ||
| }, | ||
| { | ||
| "path": "../controller-utils" |
There was a problem hiding this comment.
This dependency is present in devDependencies but was missing as a reference.
| "path": "../phishing-controller/tsconfig.build.json" | ||
| }, | ||
| { | ||
| "path": "../multichain-account-service/tsconfig.build.json" |
There was a problem hiding this comment.
These dependencies are present in dependencies but were missing as references.
| "path": "../transaction-controller" | ||
| }, | ||
| { | ||
| "path": "../multichain-account-service" |
There was a problem hiding this comment.
These dependencies are present in dependencies but were missing as references.
| "references": [ | ||
| { | ||
| "path": "../controller-utils/tsconfig.build.json" | ||
| "path": "../messenger/tsconfig.build.json" |
There was a problem hiding this comment.
base-controller no longer depends on controller-utils. It now lists json-rpc-engine as a dev dependency.
| "path": "../transaction-controller/tsconfig.build.json" | ||
| }, | ||
| { | ||
| "path": "../messenger/tsconfig.build.json" |
| "path": "../messenger/tsconfig.build.json" | ||
| }, | ||
| { | ||
| "path": "../approval-controller/tsconfig.build.json" |
| "path": "../approval-controller/tsconfig.build.json" | ||
| }, | ||
| { | ||
| "path": "../eth-block-tracker/tsconfig.build.json" |
| "path": "./packages/user-operation-controller" | ||
| }, | ||
| { | ||
| "path": "./packages/eip-5792-middleware" |
There was a problem hiding this comment.
Not sure how these were never added to the root tsconfig 🤔
There was a problem hiding this comment.
IIRC ts-bridge resolves these either way if they are specified as references in other packages. Makes sense to add them here though.
|
No dependency changes detected. Learn more about Socket for GitHub. 👍 No dependency changes detected in pull request |
| "path": "../json-rpc-engine" | ||
| }, | ||
| { | ||
| "path": "../network-controller" |
There was a problem hiding this comment.
No longer a dependency.
|
@SocketSecurity ignore npm/@metamask/preferences-controller@23.1.0 This is our package. |
|
Adding |
|
Curious if our team should be co-codeowners of |
I do believe we should |
We use project references to tell TypeScript and other tools about the
structure of the monorepo. Both the root- and package-level tsconfig
files have a `references` field which is used to link packages together.
All packages that we want to build and publish need to be present in
`references` within the root `tsconfig.json` and `tsconfig.build.json`
files, and the `references` field in both root-level and package-level
tsconfig files need to list all internal dependencies.
However, manually keeping all of these references up to date as packages
are added or dependencies are updated is a pain. There are cases where
packages were not published or type errors occurred because the
references were not correctly kept in sync.
We don't need to do this manual work. We can infer root references by
scanning workspaces, and we can infer references for an individual
package by scanning that package's `dependencies` for other workspace
packages.
This commit adds a script that can be run on both the root workspace and
child workspaces to check and/or regenerate the `references` field for
each tsconfig file so that it is perfectly kept in sync with
dependencies throughout the monorepo. There are also some package
scripts for use:
- Root level
- **`lint:tsconfigs`:** Validates the root `tsconfig.json` and
`tsconfig.build.json`, erroring if any are out of sync.
- **`lint:tsconfigs:all`:** Validates all `tsconfig.json` and
`tsconfig.build.json` across the monorepo, erroring if any are out
of sync.
- **`lint:tsconfigs:fix`:** Regenerates the root `tsconfig.json` and
`tsconfig.build.json`.
- **`lint:tsconfigs:fix:all`:** Regenerates `tsconfig.json` and
`tsconfig.build.json` files across the monorepo.
- Package level
- **`lint:tsconfigs`:** Validates `tsconfig.json` and
`tsconfig.build.json` in the package, erroring if any are out of
sync.
- **`lint:tsconfigs:fix`:** Regenerates `tsconfig.json` and
`tsconfig.build.json` in the package.
As the names indicate, tsconfig file validation is also a part of the
lint pipeline, so CI will now fail if any files are out of date.
Finally, it's worth noting that there are some existing solutions in the
TypeScript community, some of which are documented in [this issue][1],
but all of which were rejected for various reasons:
- **[`typescript-monorepo-toolkit`][2]:** Doesn't update references for
individual packages based on `dependencies`
- **[`update-ts-references`][3]:** Works, but re-sorts all references,
and drops the leading `./` from references in root tsconfig files;
also, generated files fail Prettier validation
- **[`@monorepo-utils/workspaces-to-typescript-project-references`][4]:**
Works, but re-sorts all references, and drops the leading `./` from
references in root tsconfig files; also generated files fail Prettier
validation
Essentially, by building our own script, we get to control the exact
changes that are made to tsconfig files, and we get to run all files
through Prettier so that engineers do not have to reformat them
manually.
[1]: microsoft/TypeScript#25376
[2]: https://github.com/Bnaya/typescript-monorepo-toolkit
[3]: https://github.com/eBayClassifiedsGroup/update-ts-references
[4]: https://github.com/azu/monorepo-utils/tree/master/packages/@monorepo-utils/workspaces-to-typescript-project-references
1ef5070 to
f581e73
Compare
@cryptodev-2s Update: I think once we're happy with this PR, we can just force-merge it instead of updating codeowners. We don't update |
|
This is now ready for review again! |
| workspaces, | ||
| }); | ||
| const sortedExpectedWorkspaces = [...expectedPackageNames] | ||
| .sort((a, b) => a.localeCompare(b)) |
There was a problem hiding this comment.
Does our target allow toSorted?
| .sort((a, b) => a.localeCompare(b)) | |
| .toSorted((a, b) => a.localeCompare(b)) |
There was a problem hiding this comment.
Good callout. These are scripts, so it really depends on the Node version. It looks like toSorted was added in ES2023, which is supported at least in the latest version of Node 20.x: https://node.green/#ES2023. So I think we should be good to use toSorted here.
There was a problem hiding this comment.
Actually... this would require changing our lib setting (we use ES2020 right now). We could change it to ES2023 across the board, but I tried this and even though our target is still ES2020 it doesn't seem that toSorted gets compiled down to sort. Plus as Cursor points out, technically we still support Node 18 in node.engines. So... maybe this is not a good idea. I've reverted these changes in 16d5dc1.
| * Packages whose tsconfig files are intentionally excluded from linting and | ||
| * fixing, e.g. because their references are managed by hand. | ||
| */ | ||
| const EXCLUDED_PACKAGE_NAMES = new Set(['@metamask/snap-account-service']); |
There was a problem hiding this comment.
It appears that @metamask/snap-account-service and @metamask/account-tree-controller have a circular dependency on each other. The Accounts team fixed this problem by copying types from account-tree-controller and leaving @metamask/account-tree-controller out from tsconfig.json / tsconfig.build.json: https://github.com/MetaMask/core/blob/60bb56c7726937935c94744d9b478adb8d9cbfc3/packages/snap-account-service/tsconfig.json.
Curiously, snap-account-service's package.json still includes account-tree-controller in the list of dependencies. I don't think this is necessary. I have reached out to the Accounts team to see if I can remove this. If we can do this then we don't this exception.
There was a problem hiding this comment.
I've fixed snap-account-service and have dropped the exclusion of this package from this PR: 13fb9ef
| * Produces an updated `references` list within a tsconfig file that preserves | ||
| * the order of existing references, removes extras, and adds missing ones in | ||
| * the order they appear in `newReferences`. |
There was a problem hiding this comment.
Do we need to preserve order of existing references? I think it would be cleaner if we just alphabetically sort everything.
There was a problem hiding this comment.
I thought about that, but we haven't been enforcing sorting, so every single package's tsconfig files would likely have to be updated. I figured it would be more difficult to understand the diffs in this PR if I did this. I can turn this on in this PR, but what do you think if I did it in another PR?
There was a problem hiding this comment.
Doing it in a separate PR makes sense to me.
| ["internal", "parent", "sibling", "index", "unknown"] | ||
| ] | ||
| }, | ||
| "sortPackageJson": { |
There was a problem hiding this comment.
We should probably just enable this (in a separate PR). We did it previously with Prettier, not sure why we didn't enable this for Oxfmt.
| "path": "./packages/user-operation-controller" | ||
| }, | ||
| { | ||
| "path": "./packages/eip-5792-middleware" |
There was a problem hiding this comment.
IIRC ts-bridge resolves these either way if they are specified as references in other packages. Makes sense to add them here though.
Co-authored-by: Maarten Zuidhoorn <maarten@zuidhoorn.com>
…Mask#9493) ## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> In a future commit, we want to automatically synchronize the `references` field in each package's tsconfig files with its dependencies. Currently, we would have to make an exception for `snap-account-service`, as it lists `account-tree-controller` as a dependency but purposefully excludes it from its tsconfig files to avoid a circular reference. However, this manual bookkeeping is unnecessary, as `snap-account-service` already works around the circular dependency by copying types from `account-tree-controller` instead of importing them. So the dependency is unnecessary and we can drop it from `snap-account-service`'s `package.json`. ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> Unblocks MetaMask#8384. ## 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](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Dependency and documentation-only change; no runtime or API code changes, with types already duplicated locally. > > **Overview** > Removes **`@metamask/account-tree-controller`** from `@metamask/snap-account-service`’s declared dependencies and updates the monorepo dependency graph (`README.md`, `yarn.lock`). The package already avoids importing that controller and uses **locally mirrored types** in `src/types.ts` to break the `account-tree-controller` ↔ `multichain-account-service` ↔ `snap-account-service` cycle. > > The long **tsconfig** comments that documented why `account-tree-controller` was omitted from project references are deleted now that the npm dependency no longer exists—references stay limited to `keyring-controller` and `messenger`. This aligns `package.json` with actual build/runtime usage so future automation can sync tsconfig `references` from dependencies without a special-case exception. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit b7c3e84. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> Oxfmt has the ability to alphabetically sort scripts defined in `package.json` files across the monorepo. This commit enables this feature and corrects lint violations. ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> Extracted from MetaMask#8384. ## 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](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Tooling and JSON key ordering only; no application logic or script command changes. > > **Overview** > Enables **oxfmt** to alphabetically sort `scripts` in `package.json` files by adding `sortPackageJson.sortScripts: true` to `.oxfmtrc.json`. > > The diff applies that ordering to the root `package.json` and `packages/wallet-cli/package.json` (e.g. `create-release-branch`, `postinstall`, `skills`, and `test:prepare` move to their sorted positions). **Script commands are unchanged**—only key order. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 0439165. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## Explanation `sentinel-api-service` was missing `lint:tsconfigs` and `lint:tsconfigs:fix` after MetaMask#8384 was merged. ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## 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](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Only `package.json` script entries change; no runtime or API behavior is affected. > > **Overview** > Adds **`lint:tsconfigs`** and **`lint:tsconfigs:fix`** to `@metamask/sentinel-api-service`’s `package.json`, using the same shared `../../scripts/lint-tsconfigs/lint-tsconfigs.mts` entry points as other packages. > > This brings the package in line with the monorepo convention introduced in MetaMask#8384 so tsconfig lint can run locally and in CI for this package too. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 7ad22af. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## Explanation Update `bridge-status-controller` package from `74.2.0` to `74.3.0`. <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## 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](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Version and changelog-only release with no code diff; consumers should note 74.3.0’s batch quote-status behavior when upgrading. > > **Overview** > **Monorepo release `1126.0.0`** bumps the root `@metamask/core-monorepo` version from `1125.0.0` and publishes **`@metamask/bridge-status-controller` `74.3.0`** (from `74.2.0`) with an updated package version and changelog. > > The new **`74.3.0`** changelog section documents behavior that ships with this release tag: **batch sell (EIP-7702 / nested batch)** support in the quote-status flow so every quote in one batch is reported to the backend as `SUBMITTED` under a shared source tx hash and `txMetaId`, with shared finalization on confirm/fail ([MetaMask#9514]). A **Changed** entry notes tsconfig project-reference sync with internal deps ([MetaMask#8384]). Compare links for `[Unreleased]` and `[74.3.0]` are updated accordingly. > > There are **no application source changes** in this diff—only `package.json` version fields and `CHANGELOG.md` release bookkeeping. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 24b0fa0. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> 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 <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> To merge MetaMask#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](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!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. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 2426a9b. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
Explanation
Problem
We use project references to tell TypeScript and other tools about the structure of the monorepo. Both the root- and package-level tsconfig files have a
referencesfield which is used to link packages together. All packages that we want to build and publish need to be present inreferenceswithin the roottsconfig.jsonandtsconfig.build.jsonfiles, and thereferencesfield in both root-level and package-level tsconfig files need to list all internal dependencies.However, it's a pain to keep references up to date, especially as as packages are added or dependencies are updated. There are cases in the past, in fact, where packages were not published or type errors occurred because the references were not correctly kept in sync.
Solution
We don't need to do this manual work. We can infer root references by scanning workspaces, and we can infer references for an individual package by scanning that package's
dependenciesfor other workspace packages.This commit adds a script that can be run on both the root workspace and child workspaces to check and/or regenerate the
referencesfield for each tsconfig file so that it is kept in sync with dependencies throughout the monorepo. There are also new package scripts for use:lint:tsconfigs: Validates the roottsconfig.jsonandtsconfig.build.json, erroring if any are out of sync.lint:tsconfigs:all: Validates alltsconfig.jsonandtsconfig.build.jsonacross the monorepo, erroring if any are out of sync.lint:tsconfigs:fix: Regenerates the roottsconfig.jsonandtsconfig.build.json.lint:tsconfigs:fix:all: Regeneratestsconfig.jsonandtsconfig.build.jsonfiles across the monorepo.lint:tsconfigs: Validatestsconfig.jsonandtsconfig.build.jsonin the package, erroring if any are out of sync.lint:tsconfigs:fix: Regeneratestsconfig.jsonandtsconfig.build.jsonin the package.As the names indicate, tsconfig file validation is also a part of the lint pipeline, so CI will now fail if any files are out of date. To make sure this doesn't happen in the future, this commit also corrects tsconfig files across the board to add missing references or remove extra references.
Why hand-roll a solution?
There are some existing solutions for syncing references within the TypeScript community, some of which are documented in this issue. However, I reviewed them and rejected them for various reasons:
typescript-monorepo-toolkit: Doesn't update references for individual packages based ondependenciesupdate-ts-references: Works, but re-sorts all references, and drops the leading./from references in root tsconfig files; also, generated files fail Prettier validation@monorepo-utils/workspaces-to-typescript-project-references: Works, but re-sorts all references, and drops the leading./from references in root tsconfig files; also generated files fail Prettier validationMy thought is that by building our own script, we get to control the exact changes that are made to tsconfig files, and we get to run all files through Oxfmt so that engineers do not have to reformat them manually.
References
Closes #966.
Also closes https://consensyssoftware.atlassian.net/browse/WPC-649.
Checklist
Note
Medium Risk
Wide monorepo tsconfig and declared-dependency changes can affect composite builds; a few packages gain runtime deps to match messenger/types usage.
Overview
Adds
lint-tsconfigs(scripts/lint-tsconfigs/lint-tsconfigs.mts) to validate or regeneratereferencesin root and packagetsconfig.json/tsconfig.build.jsonfrom workspace layout and each package’s internaldependencies. Rootlintand CI now runlint:tsconfigs:all; every package getslint:tsconfigs/lint:tsconfigs:fixscripts.This PR realigns references repo-wide (adds missing project refs, drops extras, normalizes path formatting) and fixes a few dependency/tsconfig mismatches the linter surfaced: e.g.
@metamask/preferences-controlleroneip-5792-middleware,@metamask/controller-utilsonkeyring-controller, and README dependency edges. ESLint now coversscripts/**/*.{ts,mts}and.mtsfor TypeScript rules.Small follow-on code tweaks: stricter typing in
permission-middleware, removal of aPerpsController@ts-expect-errorafter reference fixes.Reviewed by Cursor Bugbot for commit 2886d3b. Bugbot is set up for automated code reviews on this repo. Configure here.