Fix: ENS getEnsName() should enforce normalization#4756
Conversation
|
@adraffy is attempting to deploy a commit to the Wevm Team on Vercel. A member of the Team first needs to authorize it. |
|
commit: |
adraffy
changed the title
getEnsName should enforce normalizationgetEnsName() should enforce normalization
| type ReadContractParameters, | ||
| readContract, | ||
| } from '../public/readContract.js' | ||
| import { normalize } from '../../ens/index.js' |
There was a problem hiding this comment.
what would it take for ens-normalize to be much lighter in terms of bundle size? :D
There was a problem hiding this comment.
Since this is an async context, switch to dynamic import and guard it with a regex that covers common cases?
Now that LLMs are pretty good, I could revisit the normalization compression logic.
There was a problem hiding this comment.
Or, can you tell me what minimum JS engine you're supporting? There is an approach that leverages regex \p.
The actual library logic is extremely small — nearly all of the size is the compressed Unicode data.
I've been contemplating making a ens-normalize.ts variant since the current library is basically the research version and all of the other language ports are clean and typed.
getName previously coerced the reverse-resolved name via normalise(), silently returning a different name than what was resolved. It now uses viem's normalize() to verify the name is already normalised and returns null otherwise, matching viem's getEnsName (wevm/viem#4756) and v5. Applies to both the match and allowMismatch paths. Preserves the encode/decode batching API and the existing return body. Closes WEB-533
2 participants
ENSIP-23 states:
getEnsName()to returnnullif not normalized