Remove the need for peer dependencies between controller packages
- Dominant language
- TypeScript
- Stars
- 413
- Forks
- 308
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 253
Description
## Problem Statement
More and more controllers rely on other controllers to do their work. Because controllers are intended to communicate via the messaging system, it is important that the correct versions of controllers be used at all times. Because large parts of the Extension are still written in JavaScript, we make use of peer dependencies to enforce this fact.
However, there is a big problem with peer dependencies: when a new major version of a controller is released, all dependent packages must also be released and bumped via a major, and then all controllers within the release must be upgraded in clients. This means that a simple change can turn into a lot of work for client engineers. Not only is this a problem now, but it is a problem that is getting worse and worse over time as more and more controllers are coupled together. This is unfortunate, as it greatly damages the mission that we have to improve velocity for other teams, and it creates more work for us to retrain them to use the framework correctly.
## Proposed Solution
If all of the initialization code in the Extension codebase were written in TypeScript, then we could use TypeScript to enforce messenger types, and it would diminish the number of cascading releases. In fact, some time ago, an [organization-wide initiative](https://github.com/MetaMask/decisions/blob/main/decisions/core/0005-modular-controller-initialisation.md) was started to do just this. We should do our part and follow the same pattern for the controllers that we code-own. Then, we should help other teams finish their part, too. This also assists our team in developing the wallet library later, as the more code follows the initialization pattern, the easier it is for us to move it into the wallet library.
There may be other ways we can achieve this as well.
## Blocking Issues
- [x] https://github.com/MetaMask/metamask-extension/issues/29530
- [x] https://github.com/MetaMask/metamask-extension/issues/29528
- [x] https://github.com/MetaMask/metamask-extension/issues/29553
- [x] https://github.com/MetaMask/metamask-extension/issues/29554
- [x] https://github.com/MetaMask/metamask-extension/issues/29557
- [x] https://github.com/MetaMask/metamask-mobile/issues/12875
- [ ] https://github.com/MetaMask/metamask-mobile/issues/12876
- [x] https://github.com/MetaMask/metamask-mobile/issues/12881
- [x] https://github.com/MetaMask/metamask-mobile/issues/12893
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading the proposed modular controller initialization decision and reviewing the linked blocking issues, especially the one still open. Identify which controller packages in this monorepo use peer dependencies and what initialization changes are already underway. Done would require an agreed approach and coordinated migration, but the issue does not name specific files or tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- backend
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100