adapter-evm: let createExplorer take an explorer-only config (no rpcUrl)
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 76/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- typescript
- Ambito
- blockchain, developer-experience
Direzione di ricerca
Leggi packages/adapter-evm-core/src/capabilities/explorer.ts e packages/adapter-evm-core/src/configuration/explorer.ts per individuare quali campi di configurazione usano createExplorer e resolveExplorerConfig. Definisci e applica un tipo di configurazione explorer più ristretto che consenta di creare un explorer senza rpcUrl, mantenendo la compatibilità con le configurazioni di rete complete. Il lavoro è completato quando il tipo pubblico accetta una configurazione solo explorer e gli usi esistenti restano validi.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
createExplorer takes a full NetworkConfig (explorer.ts#L6-L17), but at runtime it only reads the explorer side of it through resolveExplorerConfig (configuration/explorer.ts): id, name, explorerUrl, apiUrl and the API key lookups. It never reads rpcUrl.
In a browser app that shouldn't ship RPC URLs (a bank operator console, in my case), we want explorer links without putting an RPC endpoint in the bundle. Today that means building the config with rpcUrl: '' just to satisfy the type, which works but reads like a hack.
Suggested, non-breaking: let createExplorer accept a narrower type, e.g. Pick<EvmNetworkConfig, 'id' | 'name' | 'ecosystem' | 'explorerUrl' | 'apiUrl' | …> (whatever resolveExplorerConfig actually reads), or export an ExplorerNetworkConfig type for it. A full NetworkConfig still satisfies it, so current callers don't change.
- Lingua principale
- TypeScript
- Stelle
- 2
- Fork
- 2
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di OpenZeppelin/openzeppelin-adapters
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
Tutte le issue di OpenZeppelin/openzeppelin-adapters
Issue simili
-
grep and find tools search inside VCS directories (.git, .svn, .hg, .jj)Forse già presa @acmerfight l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
earendil-works/pi#12084 ·
I maintainer di solito rispondono entro 1 giorno
-
comp/desktop P3 type/feature
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
NousResearch/hermes-agent#154285 ·
I maintainer di solito rispondono entro 1 giorno
-
agent-reported bug from-app needs-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
nightly-labs/openbot#8154 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
jdx/mise-action#730 ·
I maintainer di solito rispondono entro 1 giorno
-
area:cards enhancement hand-tail ready-for-agent
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
fil-donadoni/tolaria#9275 ·
I maintainer di solito rispondono entro 1 giorno