[explorer/frontend] feat: add Symbol frontend variant shell#2217
Open
daoka wants to merge 5 commits into
Open
Conversation
added 5 commits
May 27, 2026 15:13
Introduce the frontend variant boundary so shared API imports resolve through the selected platform while preserving the existing NEM behavior as the default. Move the NEM API implementations behind variants/nem and keep the public api modules as compatibility wrappers. Add config/env fallback coverage and the app config bootstrap path needed by the variant selector.
Add the browser build plumbing needed by the Symbol runtime shell without changing the default NEM platform behavior. Transpile the Symbol SDK, alias optional Node/WASM-only crypto paths to frontend-safe stubs, and add the runtime dependencies used by Symbol address formatting.
Add the minimal Symbol frontend shell on top of the variant boundary so NEXT_PUBLIC_PLATFORM=symbol can render against current Symbol REST responses while deeper explorer features remain follow-up work. This includes Symbol assets, theme variables, runtime adapters, temporary node proxy hardening, and focused tests for transaction mapping, config bootstrap safety, and unsupported filter behavior.
Symbol SDK pulls @noble/hashes 2.x, which requires Node >= 20.19.0 and can fail the CI setup install step on older Node 20 runners with engine checks enabled. Pin @noble/hashes to 1.8.0 through the frontend dependency graph so Symbol SDK remains available while keeping the install compatible with the current CI runtime.
The CI coverage check dropped below the 95% line threshold after adding the Symbol runtime shell. Add Symbol account adapter coverage for accounts/search and account info responses so the tests verify account normalization while restoring the required coverage margin.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## dev #2217 +/- ##
==========================================
- Coverage 96.90% 96.69% -0.22%
==========================================
Files 267 273 +6
Lines 19379 19880 +501
Branches 215 215
==========================================
+ Hits 18779 19222 +443
- Misses 594 652 +58
Partials 6 6
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is the current behavior?
The explorer frontend is effectively NEM-only. Public modules under
explorer/frontend/api/*contain the NEM API mapping directly, so adding Symbol support requires editing shared frontend code and makes the Symbol work too large to review safely.The frontend also assumes a single default asset/config/theme path. There is no variant boundary for selecting NEM or Symbol runtime behavior from
NEXT_PUBLIC_PLATFORM/PLATFORM.What's the issue?
Symbol Explorer work needs to be split into smaller PRs. Without a frontend variant boundary, follow-up Symbol pages and adapters would mix Symbol-specific behavior into shared code or into the existing NEM implementation.
This PR is intended to provide only the minimum frontend shell needed for Symbol startup and review:
How have you changed the behavior?
Added frontend variant selection for
nemandsymbol.explorer/frontend/variants/index.jsto resolve the active variant fromNEXT_PUBLIC_PLATFORM || PLATFORM || 'nem'.variants/nem/api/*.api/*.jsmodules as compatibility wrappers so existing imports continue to work.variants/nem/api/*matches the correspondingdevapi/*implementation files.Added a minimal Symbol runtime shell.
DocumentHead, page config, theme variables, fonts, and runtime assets.Added build/runtime support needed by Symbol.
This is not intended to be a complete Symbol Explorer implementation. Feature-complete Symbol list/detail behavior remains follow-up work.