Backport adraffy/[email protected] to ethers@5

[adraffy]

• Replaced ens-normalize/ directory with almost 1:1 port w/types
  • replaced Set with {[x]: x} and membership with set[x] or x in set
  • replaced Map with {}
  • replaced class Emoji with extra wrapper
• validate.ts runs ens_normalize() through tests.json → no errors

---

• Simplified ens-normalize()-related calls in namehash.ts, functionality unchanged
• Added max argument to dnsEncode()

[ricmoo]

A few quick notes I've noticed in a few places:

• all imports that reference local files must include the extension, otherwise lots of things break; e.g. "import foo from "./foo.js" instead of "import foo from "./foo".
• I avoid non-ASCII7 characters in source as this eliminates issues in many console-based editors and terminal emulators, as well as prevents any concerns regarding trojan code exploits, including in comments and jsdocs

There are a lot of changes that spook me every time I read over this PR. Is it possible to not include the nf component for this v5 change? Is there a way to mostly just update the base64-encoded data and add an extra function or so where necessary? Just to minimize the changes?

I also need to analyze the size with this change a bit more... Do you have any info on the size difference in the /packages/ethers/dist/ files?

[adraffy]

• all imports that reference local files must include the extension, otherwise lots of things break; e.g. "import foo from "./foo.js" instead of "import foo from "./foo".

I can make this change and remove the emoji from the comments, I was just trying to satisfy whatever TSC was saying.

I 100% agree that the extension-less includes are insane. I have a hard time reasoning about TSC builds as everyone does something different.

---

There were significant changes from your early port of normalize to the final, eg. script (group) and confusable logic.

In general, I can't do much about the file size, as it's the only the solution to: "you have a JS engine with unknown versions of Unicode, what do?"

With async import, which I assume is not allowed in v5, I could dynamically import significantly smaller norm libraries using runtime capability checks, but I'm unsure how to package code like that, when this is just a small library in a framework in someone else's project.

You don't need the NF part but considering this is a legacy build that's going to deployed on aging platforms, it's literally the use-case for a system-independent version of Unicode NF. The issue is that the % of names impacted by NF divergences is small. My goal was to make it so ens_normalize() works without any outside feature assumptions.

I can replace this with the system shim: https://github.com/adraffy/ens-normalize.js/blob/main/src/nf-native.js

---

The other changes just involve removing duplicated logic.

• Names that are normalized can be split on "."
• Names that are normalized round-trip picky UTF-8 coders (eg. Text{En|De}coder)
• dnsEncode() should use 255 char limit as discussed previously

The rest of the code is exactly the same as my currently library except the arguments are typed to satisfy TSC.

[adraffy]

• files should be ASCII7
• fixed mangled decoder.ts --- I'm still unclear how my PR got screwed up
• changed extensions to explicit
• removed validate/tests.json
• changed nf to system