hardhat
hardhat copied to clipboard
Option to create custom node startup
Feedback
For my project, I want to have a custom way to create a Hardhat node that is instrumented with my own logic instead of the Hardhat one (specifically, we want opentelemetry support)
What worked in Hardhat v2
In hardhat v2, this was possible with either:
TASK_NODE_CREATE_SERVER(as mentioned here)- By simply doing
import { JsonRpcServer } from "hardhat/internal/hardhat-network/jsonrpc/server.js";
Why it doesn't work in Hardhat v3
In Hardhat v3, this is not possible:
- There is not only a monlithic
nodewhich not only does too much for my use-case, it also has no return type - Doing
import { JsonRpcServer } from "hardhat/internal/builtin-plugins/node/json-rpc/server.ts";doesn't work because the path is not publicly exported
I can copy-paste the JsonRpcServer as-is into my repo, but that's not ideal since this folder also depends on builtin-plugins/network-manager as well
Hey @SebastienGllmt thanks for opening the issue. Can I try and understand the use case more clearly. The goal is to get opentelemetry integrated with all requests going through the Hardhat node connecting to a remote network? And it looks as if there aren't appropriate extension points or the equivalent of HH2 where you could create a server and wrap with opentelemetry support?
Correct, but not just of ongoing requests, but also of startup logs as well
This is useful for us because we primarily use Hardhat with multiple EVM nodes, and unless we have something like opentelemetry to separate the nodes by network it's hard to properly debug what is going on
This sounds reasonable. We are moving into a direction where things are APIs rather than just tasks, and "node` has been an exception so far.
How do you think this could look like? Maybe it doesn't need to be exported in the HRE, or it can be part of the network manager.
How do you think this could look like?
Just having way to access JsonRpcServerImplementation is sufficient I think, since hre.network.connect (and subsequent connection.viem) already do most of the heavy lifting
That being said, an option is just to integrate opentelemetry directly into Hardhat (or think about what a plugin to enable it would look like if for some reason you really don't want it in core) since I assume it would be useful for anybody else looking to debug multiple networks with hardhat (depends if you want to spend time on that though). If it was directly part of Hardhat, I wouldn't need to override the node command anymore
Maybe to summarize:
- Expose the path so I can import
JsonRpcServerImplementationdirectly - Expose an API that initializes a
JsonRpcServerImplementationas part ofNetworkManager - Add OpenTelemetry to hardhat as a plugin
- Add OpenTelemetry to hardhat as part of the core feature set