chore(namehash-ui): Copy shared components from ENSAdmin & ENSAwards

[Y3drk]

Substantial PR → Copy shared components from ENSAdmin & ENSAwards

---

Reviewer Focus (Read This First)

What reviewers should focus on

• Feel free to critique the overall structure of the package, that's where I went by my instinct the most
• The vast majority of changes in this PR are just copy-pasting components from ENSAwards & ENSAdmin and adding the package's prefix to their styles
• The only components with major alignments are packages/namehash-ui/src/components/identity/ResolveAndDisplayIdentity.tsx:ResolveAndDisplayIdentityProps and packages/namehash-ui/src/components/registrar-actions/RegistrarActionCard.tsx. I suggest reasoning about the changes made, focusing on differences in how each of our apps displays registrar-actions
• Overall, this PR brings a lot of changes, but the related risk is low, as all of these components have not been replaced yet, just copied.

---

Problem & Motivation

Why this exists

• This PR is a part of a larger effort described in detail in Create new package in ENSNode monorepo: namehash-ui #906 Issue, which in turn is part of Epic: NameHash UI #1467
• It is generally supposed to complete a joined Phase 3 & Phase 4 of the strategy suggested in the aforementioned Issue.

---

What Changed (Concrete)

What actually changed

1. Went through a preliminary list of components to move into the package
2. For each of them, explored the possible differences between them in ENSAwards & ENSAdmin and decided whether the component should be copied or not. I also created a variant where a component could be moved, but that action was postponed either due to a low priority or potentially significant effort to refactor them and/or resolve differences between ensadmin and ensawards instances.
3. Copied chosen components, applied the package's prefix to their styles, and performed some refactors to make them usable in both apps if needed.
4. Adjusted package.json and README.md files accordingly.

---

Design & Planning

How this approach was chosen

• Currently simply following the strategy proposed in Create new package in ENSNode monorepo: namehash-ui #906 → this PR is just another part of it, constituting combined Phase 3 & Phase 4

• Planning artifacts: Issue Create new package in ENSNode monorepo: namehash-ui #906
• Reviewed / approved by (only if there was a real review): N/A

---

Self-Review

What you caught yourself

• I appreciate that the refactor of packages/namehash-ui/src/components/identity/ResolveAndDisplayIdentity.tsx:ResolveAndDisplayIdentityProps might seem weird (the addition of identityLinkDetails), but with how our registrar actions display is designed across our apps, I found it the best way to keep the code usable across both of them without any design changes. Feel free to attack it.

• Bugs caught: None → planning a bughunting for when I actually apply the package in our apps.
• Logic simplified: None (new code added, nothing changed outside the package)
• Naming / terminology improved: -
• Dead or unnecessary code removed (or why none was): None → will be removing the redundant components from ENSAdmin & ENSAwards once I successfully apply the package's components there.

---

Cross-Codebase Alignment

• Related code checked: Went through the preliminary components list and checked out the relevant components in ensawards, ensadmin, and docs/ensrainbow.io.
• Reviewed but unchanged: See the preliminary components list → ❌ move cancelled
• Deferred alignment (with rationale): See the preliminary components list → 🔁 postponed

---

Downstream & Consumer Impact

Who this affects and how

• Other than the namehash-ui itself, this PR shouldn't affect any of our apps, docs, or packages.

• Public APIs affected: None
• Docs updated: Only contains updates to namehash-ui/README.me
• Naming decisions worth calling out: None

---

Testing Evidence

• Testing performed: Only the CI tests that were run on the PR, plus a self-review of the code.
• Known gaps: The components have not been applied anywhere yet, so I did not check whether some runtime errors occur or some layouts are broken, etc. → I want these "tests" to be a part of future PRs where I'll apply the package in our apps.
• What reviewers have to reason about manually (and why): Any alignment refactor changes made to copied components → I plan to carefully review these in action as I apply the package in our apps in later PRs, as they seem fine in code when I review them now.
• If this is wrong, what breaks first: The only thing possibly affected by mistakes made in this PR would be the namehash-ui package. I expect that nothing bad should happen, but even if it does, it won't affect any of our apps, as none of them use the package yet.

---

Scope Reductions

• Follow-ups: See the preliminary components list → 🔁 postponed
• Why they were deferred: In my opinion, all of the postponed components are worth including in the package, but doing that right now is not strictly necessary, cause for now they are only used in one of the apps. Also, for most of them, including them in the package would require a significant refactor to make them 'unified' / usable in both apps at once.

---

Risk Analysis

How this could go wrong

• Assumptions this PR relies on: The copied components will retain their styles and runtime characteristics.
• Likely failure modes: Runtime errors when trying to use the package's components and/or some broken layouts for these components (worth noting that the styling errors are highly unlikely to happen)
• Blast radius if it breaks: Only the namehash-ui package

• Risk areas: Only the namehash-ui package
• Mitigations or rollback options: Do not use the package anywhere until the components are confirmed to work (my plan for my next PR is to include them in ENSAdmin and iron out any possible errors)
• Named owner if this causes problems: @Y3drk

---

Pre-Review Checklist (Blocking)

• I reviewed every line of this diff and understand it end-to-end
• I'm prepared to defend this PR line-by-line in review
• I'm comfortable being the on-call owner for this change
• Relevant changesets are included (or explicitly not required)

[changeset-bot]

🦋 Changeset detected

Latest commit: 7ce853e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 17 packages

Name	Type
@namehash/namehash-ui	Major
ensindexer	Major
ensadmin	Major
ensrainbow	Major
ensapi	Major
fallback-ensapi	Major
@ensnode/datasources	Major
@ensnode/ensrainbow-sdk	Major
@ensnode/ponder-metadata	Major
@ensnode/ensnode-schema	Major
@ensnode/ensnode-react	Major
@ensnode/ponder-subgraph	Major
@ensnode/ensnode-sdk	Major
@ensnode/shared-configs	Major
@docs/ensnode	Major
@docs/ensrainbow	Major
@namehash/ens-referrals	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
admin.ensnode.io	Ready	Preview, Comment	Jan 13, 2026 10:12am
ensnode.io	Ready	Preview, Comment	Jan 13, 2026 10:12am
ensrainbow.io	Ready	Preview, Comment	Jan 13, 2026 10:12am

[lightwalker-eth]

@Y3drk Nice updates 👍 Reviewed and shared feedback. Please feel welcome to take the lead to merge when ready. Thanks!

[lightwalker-eth]

Why is sonner only necessary for the CopyButton component? I assume this is for tooltips? Don't all our apps use tooltips and therefore don't all our apps require sonner?

[Y3drk]

@lightwalker-eth

No, these two are unrelated. I think sonner is much more similar to the pure JS alert feature than the tooltip. You can have a look at shadcn's sonner docs for more info.

Either way out of all shared components only the CopyButton uses the import { toast } from "sonner"; hence the information in the readme.

[lightwalker-eth]

Interesting, so we need sonner on top of these other tooltip libraries?

[Y3drk]

@lightwalker-eth Yes, these are separate functionalities. (See these docs for more info).

[lightwalker-eth]

@Y3drk Updates all look great. Thanks!