refactor(ens-controller): migrate from @ethersproject/providers to viem for ENS resolution - #9745
refactor(ens-controller): migrate from @ethersproject/providers to viem for ENS resolution#9745yashgo0018 wants to merge 1 commit into
@ethersproject/providers to viem for ENS resolution#9745Conversation
…em for ENS resolution This update replaces the usage of `@ethersproject/providers` with `viem` for ENS resolution in the `EnsController`. The `DEFAULT_ENS_NETWORK_MAP` has been updated to point to the ENS Universal Resolver contract address, reflecting changes in the default `ensEntries` state. Additionally, the test suite has been adjusted to accommodate these changes, ensuring compatibility with the new resolution method. Changelog entries have been updated to document these breaking changes and the transition to the new library.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
Warning MetaMask internal reviewing guidelines:
|
Explanation
EnsControllerpreviously used ethers (@ethersproject/providers) to perform reverse ENS resolution (lookupAddress/resolveName) directly against the ENS registry contract. ENS is moving to ENSv2, and the recommended integration path is the ENS Universal Resolver (ENSIP-23) — a proxy contract owned by the ENS DAO that will be upgraded in place when ENSv2 launches, allowing clients to migrate automatically.This PR replaces ethers@5 with viem, whose
getEnsNameaction resolves through the Universal Resolver (reverse()), making the controller ENSv2-compatible with no future code changes.What changed
EnsController.tsWeb3Provideris replaced with a viem client created viacreateClient({ chain, transport: custom(provider) }), wrapping the same EIP-1193 provider obtained fromNetworkController:getNetworkClientById.reverseResolveAddressnow calls viem'sgetEnsName(reverse resolution through the Universal Resolver) and keeps the existing safety pipeline unchanged: forward-verification viagetEnsAddress(normalize(domain)), rejection of zero/0x/mismatched addresses, punycode (toASCII) caching inensResolutionsByAddress, and swallowing RPC errors toundefined.DEFAULT_ENS_NETWORK_MAPnow maps Mainnet and Sepolia to the ENS Universal Resolver contract address (0xeEeEEEeE14D718C2B47D9923Deab1335E144EeEe). Ropsten, Rinkeby, and Goerli have been shut down for years, and Holesky has no Universal Resolver deployment, so these entries were removed.@ethersproject/providersremoved;viemadded.2.55.8: starting with2.55.10, viem marks its type declarations as ESM-only (_types/package.jsonwith{"type":"module"}, viem#4903), which breaks this monorepo's dual CJS/ESMts-bridgebuild (TS1479).2.55.8is the newest version with full Universal Resolver v3 support that type-checks cleanly for both output formats.viem/actionsmock ofgetEnsName/getEnsAddress. All existing test assertions are unchanged; coverage remains 100% across statements, branches, functions, and lines.Public API
No API changes. The constructor options, all public methods, messenger actions, and generated action types are byte-for-byte identical. viem does not appear anywhere in the emitted type declarations, so downstream consumers are not exposed to viem's types.
Breaking change
The exported
DEFAULT_ENS_NETWORK_MAPconstant changed: it now contains Universal Resolver addresses for Mainnet and Sepolia only (previously ENS registry addresses for six chains). The defaultensEntriesstate seeded from this map (under the.key) changes accordingly. Reverse resolution on Holesky is no longer available by default; the other removed chains were already non-functional.Changelog
Updated
packages/ens-controller/CHANGELOG.md(Unreleased):DEFAULT_ENS_NETWORK_MAPnow maps Mainnet and Sepolia to the ENS Universal Resolver contract address@ethersproject/providerswithviemfor ENS resolution; reverse resolution now goes through the ENS Universal Resolver (ENSIP-23), which makes the controller compatible with ENSv2 when it launchesTesting
yarn workspace @metamask/ens-controller run test— 41 tests pass, 100% coverage on all metricsyarn build— full monorepo build passes (both CJS and ESM outputs)yarn exec eslint packages/ens-controller— cleanyarn workspace @metamask/ens-controller run changelog:validate— passesyarn workspace @metamask/ens-controller run messenger-action-types:check— up to dateyarn constraintsandyarn lint:dependencies— pass