Create new package in ENSNode monorepo: namehash-ui

[shrugs]

Background

• We are currently duplicating a number of UI components between ENSAdmin and ENSAwards.
• This code duplication reduces our maintainability and development velocity.

Goals

• The duplicated UI components should move into a new package: @namehash/namehash-ui.
• This new package should be publicly published on NPM.
• This new package should live within the ENSNode monorepo.
• The readme file for this new package should contain a short summary for how it is intended only for use within apps built by the NameHash team.
• This package must include a copy of our standard LICENSE file.
• Remove code duplication between ENSAdmin and ENSAwards wherever possible / relevant / beneficial.
• Our DevOps scripts, changesets configs, etc. should be updated as necessary.

Non-Goals

• The namehash-ui package is for logic that is specific to and shared between apps developed by NameHash. It will be published as a public package to NPM, so technically others could use it, but we should not make efforts for items within namehash-ui to have unnecessary generality such that they have extra complexity to support use cases that we ourselves do not have. Everything in namehash-ui should be highly opinionated for our specific needs.

Suggested Strategy

Below is just a suggestion. Please feel welcome to use a different approach if you see a better plan.

1. Phase 1: Create a PR focused just on making the new package exist and being wired into our DevOps scripts, changesets configs, etc. Don't worry about moving any logic into this package yet. The goal of Phase 1 is that it will start making "Snapshot Releases" of this new package available on NPM which will help with all the work in Phase 2.
2. Phase 2: Identify all items that should move into this package between ENSNode and ENSAwards, but don't actually move any of them yet. This phase is focused on research and planning.
3. Phase 3: Move items from ENSNode into this package, but don't move anything from ENSAwards yet. This can be a distinct PR.
4. Phase 4: Move items from ENSAwards into this package, but don't change anything on ENSAwards yet to start making use of this package. This can be a distinct PR.
5. Phase 5: Update ENSAwards to start making use of this package.

Examples

• A good example of the components that could leverage this package would be elements like ResolveAndDisplayIdentity, ChainIcon, or EnsAvatar.

Notes

• It could be either a pure React app or an app using a framework that allows React integration (like Astro)
• I imagine some of the included components would use our ensnode-react hooks, that's why the provider setup might be compulsory