fix(test): restore jsdom Web Storage lost by vitest's jsdom env on Node 25+

[shin-core]

What

On Node 25+, globalThis.localStorage exists as a native accessor that evaluates to undefined when no --localstorage-file is supplied (nodejs/node#60303, still open). Vitest's jsdom environment copies jsdom's window properties onto the test global only when a key is absent — so once "localStorage" in globalThis is truthy (Node 25+), it skips copying jsdom's real Storage and leaves Node's broken undefined in place. Every apps/loopover-ui / apps/loopover-miner-ui test that touches window.localStorage then throws TypeError: Cannot read properties of undefined (reading 'clear').

CI pins Node 22 via .nvmrc, so it's green today — but local dev on a newer Node is broken, and this becomes CI-breaking the moment .nvmrc is bumped past Node 24. The upstream vitest issue (vitest-dev/vitest#8757) was closed as "non-LTS not supported", so there's no upstream fix to wait for.

Fix

jsdom's working Storage is still reachable via the raw JSDOM instance vitest exposes as globalThis.jsdom. A tiny helper (src/test/restore-jsdom-web-storage.ts in each workspace) copies localStorage/sessionStorage from globalThis.jsdom.window onto the global whenever the environment's own copy is missing, called from each vitest.setup.ts before any test runs.

• No-op on Node 22 (.nvmrc / CI): jsdom's copy is already present (globalThis.localStorage is truthy), so the guard skips every key — CI behavior is byte-identical.
• Restores both the global and the jsdom.window reference, so both localStorage and window.localStorage work in a test.

Tests

src/test/restore-jsdom-web-storage.test.ts simulates the Node 25+ broken state (a target where "localStorage" in target is true but the value is undefined) so the fix is exercised deterministically on any Node, including CI's Node 22: it asserts the shim restores a working Storage, leaves an already-working Storage untouched (the CI no-op path), no-ops without a jsdom instance, and skips a storage jsdom doesn't expose. 4/4 pass; both full UI suites stay green (415 + 332 tests).

Scope

apps/** test infrastructure only (two vitest.setup.ts + two helpers + one test) — no src/**, no runtime/UI component, no visual change.

Closes #7576

[superagent-security]

🚨 Contributor flagged. Click here for more info: Superagent Dashboard

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-21 00:32:27 UTC}

5 files · 1 AI reviewer · no blockers · readiness 100/100 · CI green · blocked

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This adds a small shim duplicated identically across two workspaces that restores jsdom's real Storage onto globalThis/window when Node 25+'s native localStorage accessor leaves it undefined, guarded so it's a true no-op on Node 22 (today's CI). The logic is sound: it only acts when `target[key]` is falsy and jsdom's own storage exists, and the accompanying test correctly simulates the Node 25 broken-but-present-key shape rather than relying on an actual Node 25 runtime, which is a reasonable way to get deterministic coverage on Node 22 CI. The fix is applied at the right layer (test setup, not application code) and is well-scoped to the stated problem.

Nits — 5 non-blocking

• The restore-jsdom-web-storage.ts helper is byte-identical in both apps/loopover-miner-ui/src/test and apps/loopover-ui/src/test; consider hoisting it into a shared test-utils package if this repo has one, to avoid the two copies drifting.
• Object.defineProperty with `configurable: true, writable: true` but no `enumerable` flag will make the restored localStorage/sessionStorage non-enumerable, unlike a plain assignment; verify nothing in the test suite relies on enumerating globalThis or window keys.
• The PR references issue fix(test): vitest jsdom environment silently loses window.localStorage on Node 25+ #7576 in comments but I cannot verify from this diff alone that fix(test): vitest jsdom environment silently loses window.localStorage on Node 25+ #7576 is the linked eligible open issue this PR closes — worth confirming in the PR body.
• Consider extracting restore-jsdom-web-storage.ts into a shared package (e.g. a `packages/test-utils`) imported by both vitest.setup.ts files instead of duplicating the file verbatim.
• Add a one-line comment cross-referencing the sibling file in the other workspace so future edits stay in sync until deduplicated.

Flagged checks (non-blocking)

• Contributor trust — Contributor flagged for review

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#7576
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 83 registered-repo PR(s), 48 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	shin-core; Gittensor profile; 83 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor

Review context

• Author: shin-core
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 83 PR(s), 0 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

Visual preview

Route	Viewport	Before (production)	After (this PR's preview)	Diff
/	desktop	before /	after /	—
/	mobile	before / (mobile)	after / (mobile)	—

Click any thumbnail to open the full-size screenshot. Before = production · After = this PR's preview deploy.

Scroll preview

Route	Before (production)	After (this PR's preview)
/	before / (scroll)	—

A short scroll-through clip (desktop) — click either thumbnail to open the full animation. Evidence for scroll-linked behavior a single screenshot can't show.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.

[JSONbored]

One gap: packages/loopover-ui-kit (@loopover/ui-kit, the design-system package consumed by both apps/loopover-ui and apps/loopover-miner-ui) has the identical jsdom + vitest setup shape — see packages/loopover-ui-kit/vitest.setup.ts / vitest.config.ts (added in #7495). It has no test touching localStorage/sessionStorage today, so it isn't currently failing, but it'll hit the exact same Node 25+ issue the moment one does, since it goes through the same populateGlobal() gap. Worth wiring restoreJsdomWebStorage() into that workspace too (mirroring what's already done for the other two) so the fix covers every jsdom-environment workspace in the repo, not just two of the three.

One gap: packages/loopover-ui-kit (@loopover/ui-kit, the design-system package consumed by both apps/loopover-ui and apps/loopover-miner-ui) has the identical jsdom + vitest setup shape — see packages/loopover-ui-kit/vitest.setup.ts / vitest.config.ts (added in #7495). It has no test touching localStorage/sessionStorage today, so it isn't currently failing, but it'll hit the exact same Node 25+ issue the moment one does, since it goes through the same populateGlobal() gap. Worth wiring restoreJsdomWebStorage() into that workspace too (mirroring what's already done for the other two) so the fix covers every jsdom-environment workspace in the repo, not just two of the three.

[JSONbored]

Misses the mark:

One gap: packages/loopover-ui-kit (@loopover/ui-kit, the design-system package consumed by both apps/loopover-ui and apps/loopover-miner-ui) has the identical jsdom + vitest setup shape — see packages/loopover-ui-kit/vitest.setup.ts / vitest.config.ts (added in https://github.com/JSONbored/loopover/pull/7495). It has no test touching localStorage/sessionStorage today, so it isn't currently failing, but it'll hit the exact same Node 25+ issue the moment one does, since it goes through the same populateGlobal() gap. Worth wiring restoreJsdomWebStorage() into that workspace too (mirroring what's already done for the other two) so the fix covers every jsdom-environment workspace in the repo, not just two of the three.