Conversation
|
crates/edr_napi/Cargo.toml
Outdated
| tracing = ["edr_evm/tracing", "edr_napi_core/tracing", "edr_provider/tracing"] | ||
| scenarios = ["rand"] | ||
|
|
||
| [profile.release] |
There was a problem hiding this comment.
cargo was reporting that this setting was ignored. Only the workspace Cargo.toml's profile are respected.
|
|
||
| [lib] | ||
| crate-type = ["cdylib"] | ||
| crate-type = ["cdylib", "lib"] |
There was a problem hiding this comment.
This is required for edr_napi_optimism to use this crate as a dependency
| @@ -0,0 +1,1193 @@ | |||
| use core::fmt::Debug; | |||
There was a problem hiding this comment.
File moved from edr_napi, with a modification to the config. This removes the dependency on napi types.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #659 +/- ##
=======================================
Coverage ? 63.07%
=======================================
Files ? 216
Lines ? 23689
Branches ? 23689
=======================================
Hits ? 14941
Misses ? 7819
Partials ? 929 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| workflow_dispatch: | ||
|
|
||
| env: | ||
| RUSTFLAGS: -Dwarnings |
There was a problem hiding this comment.
This should not have any adverse side-effects, as we also manually pass this argument to cargo clippy which should fail if there are any warnings.
For reference:
cargo clippy --workspace --all-targets --all-features -- -D warnings
5c5aac5 to
bb89e37
Compare
bb89e37 to
fb093cf
Compare
0eded9d to
0bf5709
Compare
This PR restructures the
edr_napi_coreandedr_napito be able to share code with the newedr_napi_optimismpackage.I ran into one problem that I was able to solve. Namely, when a crate that generates NAPI bindings is added as a dependency to another crate that generates NAPI bindings, the test target of the dependant crate will throw linker errors. This is a known issue. I was only able to work around it by adding the recommended rustflags to both the workspace- and project-level
.cargo/config.toml. If I only added it to the project, thecargo test --all-features --all-targets --workspacecommand would still throw the linker errors.There is currently still a bug in the
edr_napi_optimismJS tests. In the background, thehyperClient is sporadically trying to execute a future using its executor. By default, this executor usestokio::spawnbut since theedr_optimismNPM package doesn't have a tokio runtime, this panics.The solution is to specify a custom executor, but reqwest always uses the Tokio executor. An issue exists to add this executor, but a previous PR was rejected because it was deemed unnecessary.
For now, my proposal would be to merge the changes to the project layout and move forward with the release of the
GenericChainSpec, asedr_optimismwon't be exposed anyway.A future issue can then:
reqwesttokio::Runtimeof ouredrNPM package's runtimeCould you please pay special attention to these two aspects when reviewing?