Open legobeat opened 1 year ago
Its the the usage of the types SnapsGlobalObject
from @metamask/rpc-methods
and SnapController
from @metamask/snaps-controllers
thats importing all the other dependencies. I would prefer not to migrate this to the snaps repo because it isn't related to snaps, and this AccountsController
is to be shared between the clients.
Perhaps, a separate types package would be a better solution?
Naming and exact scope aside, a third repo (poly- or mono) could also be appropriate
Or maybe something like keyrings
, which could potentially include keyring-api
? :thinking:
Now that https://github.com/MetaMask/accounts exists, is that a better candidate than either of https://github.com/MetaMask/snaps or https://github.com/MetaMask/core?
Tentatively changed title accordingly.
@metamask/accounts-controller
(#1637) has started pulling in dependencies from https://github.com/MetaMask/snaps, which in their turn go back for packages from this repo.To avoid dependency cycles and release churn arising from this dynamic, I propose migrating the package to the snaps monorepo - at least as long as the relationships look like they currently do.
Hand-drawn ASCII art is the dependency tree limited to packages in MetaMask core and snaps monorepos: