ESM Support / Runtime Network Change Support

[mihaic195]

Version of Hardhat

2.12.7

What happened?

Related to: #3043

For example:
Multiple contracts with different configs are deployed programmatically, on a daily basis, on various chains. This is done through the browser using ethers.js and artifacts generated by the hardhat compilation in a next.js app.
The projects, contract tests, and hardhat config is written in TS.

I need a way to use the HRE in an ESM environment (e.g. next.js backend API) to be able to verify the said contracts using the verify:verify task. Since Next.js enforces ESM, I cannot use HRE in a next.js app.

Minimal reproduction steps

• To solve the problem above, I created a microservice in nest.js with a commonjs config.
• This allows me to create an endpoint and import HRE to run the verify:verify task once the endpoint is called.
• In the nest.js project, I copied over the solidity contracts, compiled them with the same hardhat config from next.js, and moved the generated artifacts back to the next.js app so that there is a matching bytecode between next.js and nest.js.
• Note: importing HRE was only possible if the hardhat config was written in JS, not in TS like in the next.js app.
• Having hardhat config in JS in the next.js app is not an option as my tests are written in TS, and if the hardhat config is in JS, they won't be picked up by hardhat.

At this point, I'm faced with another issue:

• The endpoint above is called with a specific chain ID based on the chain on which I want the contract to be verified. The default network is hardhat.
  So I need a way to change the network at runtime, which I was only able to do with the help of this package: https://github.com/dmihal/hardhat-change-network.

TL;DR

Because of the limitations above, I'm forced to have a separate verification microservice instead of creating a simple endpoint in a next.js app. I also have to use some sorcery to change the network at runtime.

In the end, it works, but it's far from ideal, as it requires much maintenance to do it this way.

I would gladly help in any way I can to overcome these issues if needed.

Search terms

hre, hardhat runtime environment, verification, esm, commonjs

[sshmaxime]

Hey @mihaic195, if I understood well, you want to run Hardhat on your backend service, in your case a serverless function of Next.Js, in order to call the verify task of Hardhat. This needs to be chain specific and therefore, depending on what chainId you receive in your endpoint you need to programmatically change the network accordingly ?

Is that it ?

[mihaic195]

@sshmaxime that is exactly right.
Additionally, Next.js is ESM only, so it's not possible to use Hardhat in a Next.js API endpoint, hence the reason for a separate Nest.js service using CommonJS.

[sshmaxime]

Ok, then, could you explain exactly what your issue is about, other than Hardhat is not ESM compatible yet.

[mihaic195]

Other than Hardhat is not ESM compatible yet, there is no straightforward way to change the network programmatically at runtime, except for using something like hardhat-change-network, which is a hackish way of doing it as per the package author.

[fvictorio]

Hi @mihaic195, I think what you want is covered by #3043, #2797 and maybe also #3385. #2797 is in turn blocked by #3042, which is about being able to create different HREs in runtime with different configs. In your case, this would let you create a new HRE with the proper network for each verification. Sadly, we don't have an ETA for this.

I'm going to assume that those issues cover this use case and close this one. Please let me know if you disagree.