feat: add shared AssetsService to snap-networks-utils - #80
feat: add shared AssetsService to snap-networks-utils#80ulissesferreira wants to merge 10 commits into
Conversation
Port the thin Core AssetsController read layer from the shared-assets proposal into the real shared package, stacked on WPN-1632.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Move assets under services/, use scope params, return ID maps, assert account refs, adopt with* test helpers, and fix toUiAmount trailing-zero trimming for CodeQL. Co-authored-by: Ulisses Ferreira <ulisses@hey.com>
Create mocks inside the helper, take only the callback, and use payload / assetsService / mockCoreMessenger naming. Co-authored-by: Ulisses Ferreira <ulisses@hey.com>
Follow Core's root-only exports pattern; AssetsService remains available from the package root. Leave ./logger as it came from the base branch. Co-authored-by: Ulisses Ferreira <ulisses@hey.com>
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
All alerts resolved. Learn more about Socket for GitHub. This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored. Ignoring alerts on:
|
Drop the internal account ref helper, type account IDs as AccountId, move mapControllerAsset under services/assets/utils, and export from the package root without a barrel file.
|
@SocketSecurity ignore npm/@metamask/assets-controller@11.2.0 These are first-party MetaMask packages. |
Reorder package.json dependencies and apply formatting fixes flagged by lint:misc:check.
|
@SocketSecurity ignore npm/@metamask/assets-controller@11.2.0 Reviewed transitive tree introduced by intentional |
Rename getAccountAssets to getAccountAssetsByScope with a required chain filter, update tests accordingly, and align tsconfig Jest types setup.
|
Head branch renamed to |
## 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? --> ## 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
3 participants
Summary
WPN-1632-scaffold-snap-networks-utils)shared-assets-serviceproposal into@metamask/snap-networks-utilsAssetsService,mapControllerAsset,toUiAmount, and Core messenger types, with an./assetssubpath exportTest plan
yarn workspace @metamask/snap-networks-utils run buildyarn workspace @metamask/snap-networks-utils run testyarn constraintsWPN-1632-scaffold-snap-networks-utils, notmain