alloy-rs / alloy-rs/alloy

[Feature] Move `AnyNetwork` types into their own crate(s)

Aperta
#1,598 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub
c-consensus c-rpc-types chore discuss
Lingua principale
Rust
Stelle
1.3k
Fork
668
Merge medio
2g 1h
PR unite (30g)
29

Descrizione

### Component

consensus, eips, genesis, network, json-rpc

### What version of Alloy are you on?

_No response_

### Operating System

None

### Describe the bug

per discussion here: https://github.com/alloy-rs/alloy/pull/1460#discussion_r1824406025

Currently `alloy-consensus` contains `Any` types for `Receipt` and `Header` that are then bubbled up through `alloy-rpc-types-eth` to `alloy-network`. These types are not `eth` types and it is somewhat messy to put them alongside the eth types. We have a standard pattern for adding networks to alloy, that `AnyNetwork` is currently not following, which is to create `consensus-*` and `rpc-types-*` crates

Approximate steps to take:

- create `alloy-consensus-any`, depending on `alloy-consensus`
- create `alloy-rpc-types-any`, depending on `alloy-rpc-types-eth`
- move `AnyReceipt` and `AnyHeader` from `alloy-consensus` to `alloy-consensus-any`
- move `AnyTxEnvelope` from `alloy-network` to `alloy-consensus-any`
- create type aliases for `AnyRpcHeader` and `AnyRpcBlock` in `alloy-rpc-types-any`
- change `alloy-network` to depend on `alloy-consensus-any` and `alloy-rpc-types-any`

Alternate approach would be to create only a single crate that contains both consensus and rpc types

Guida per i contributori

Apri la guida per i contributori

Valutazione

Questa issue non è ancora stata valutata.

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.