Generalize ens-deployments package

[lightwalker-eth]

Fixes #190

Related ideas: #87

Goals

• Prepare the ens-deployments package for publishing on NPM (in some future PR) for broader use by the ENS community.
• Carefully refine our documentation of important ENS nuances and subtleties.
  • Mitigate the risks that expert ENS devs might find disagreement with how this package models the details of ENS deployments.
  • Help non-expert ENS devs achieve more accurate mental models of how ENS actually works (such that they are less likely to make bad assumptions about the true implementation of ENS).

Subtasks

@lightwalker-eth has proposed a starting point for this PR. Additional work remains, including:

• Refine ens-deployments package
  • Remove any remaining use of "plugin" language within ens-deployments.
  • Remove any remaining references or dependencies to Ponder within ens-deployments
    • Refine comments / definition of SubregistryContractConfig.
    • Refine any references to ContractConfig#filter
  • Add root README.md file that provides a simple introduce to the package. Suggest lifting content from src/index.ts as relevant.
    • Identify that we make use of terminology as defined in https://www.ensnode.io/reference/terminology.
  • Refine package.json
    • Refine description field. Ex: "Catalog of ENS deployments, including key contract addresses and other attributes."
    • Refine description of package in monorepo root README.md
    • Remove ponder dependency.
    • Change viem dependency so that it falls under peerDependencies.
  • Question: Perhaps we should change the SubregistryName enum values as follows:
    • base -> base.eth
    • linea -> linea.eth
  • Question: Would it make sense to move our abis into ens-deployments?
• Refine ensnode app to make use of the new ens-deployments package structure
  • NOTE: Initial commits on this PR from @lightwalker-eth that made changes to the ensnode app are all side effects of proposed renamings within ens-deployments. Perhaps ensnode retains the concept of a "plugin" but it will need to "translate" from the generic "subregistry" definitions in ens-deployments as necessary.
• Suggest next steps on the ideas discussed in the following:
  • 0b939f4
  • https://namehash.slack.com/archives/C086Z6FNBHN/p1739210136247829

After the above items are actioned, please feel welcome to ask @lightwalker-eth to take the lead on the following:

• Document how we're fully aware there's currently no standards defined in ENS for subregistries / subregistrars. This includes how we're fully aware that the implementation of contracts for the base.eth and linea.eth subregistries are not identical to the eth subregistry.
• Make a review of the content in docs/ensnode/src/content/docs/reference/mainnet-registered-subnames-of-subregistries.mdx

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
ensnode.io	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 12, 2025 5:02pm
ensrainbow.io	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 12, 2025 5:02pm

[tk-o]

LGTM

[shrugs]

• note the duplicate registrations and their undefined behavior when running multiple plugins

[shrugs]

I've made a bunch of changes as per the above. personally in favor of keeping 'plugin' terminology on the ponder side just because it's already there and makes a lot of sense in the context of ponder. and while changing the subregistry names to base.eth or linea.eth is pretty reasonable i'm happy with them as-is.

@lightwalker-eth back to you to review my wording and follow up

[lightwalker-eth]

@shrugs Hey super updates! This package is so cool!

Reviewed and shared some suggestions with feedback 👍

[lightwalker-eth]

Ah this dependency is a little bit of a bummer. Ok to keep it, but ideally not needed.

[shrugs]

it's for the mergeAbis helper which while not necessary is definitely helpful and i think this specific dependency is acceptable since it's their utils package and not the whole ponder package

[lightwalker-eth]

This is super! Thanks!

I need to review this file 1 more time before we merge the PR. It's currently past 5am here though and quite tired. Better come back to review this file while fresh 👍

[shrugs]

@lightwalker-eth ready for re-review

[lightwalker-eth]

@shrugs PR looks awesome 🚀 Just a small point of feedback. GitHub won't let me approve this PR because I was the one who originally created it. You're welcome to take the lead on merging this PR after following up on the suggestion 👍

[lightwalker-eth]

Thanks for this updated example. Pretty cool!

Maybe I'm doing something wrong, but my understanding is that this would actually return a zero address since vitalik.eth is not wrapped by the namewrapper?

A few quick ideas:

1. Change this example to something where the value returned is a bit interesting. Ex: ask the ENS Registry for the owner of the node associated with vitalik.eth (instead of asking the NameWrapper). I expect this should then return something like: 0x220866B1A2219f40e72f5c628B65D54268cA3A9D.
2. Could we add a comment at the end of this example with a description of the expected value that would be returned?

[shrugs]

i merged my main branch (which for some reason had the docker-related changes i was making) into this branch to bring it up to date so this branch now has a bunch of changes from #224 included, which is not ideal. will take time to fix that later today. please ignore any changes related to that for the purposes of reviewing

[shrugs]

diff has been fixed