alloy-rs / alloy-rs/alloy

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

Offen
#1,598 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
c-consensus c-rpc-types chore discuss
Vorherrschende Sprache
Rust
Sterne
1.3k
Forks
668
Ø Merge
2 T. 1 Std.
Gemergte PRs (30 T.)
29

Beschreibung

### 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

Beitragsleitfaden

Beitragsleitfaden öffnen

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.