add optional chain param to viem deploy #783
Conversation
…omicFoundation#768) Also exclude BNB Test chain from the zero fee gas fee logic calculation. Resolves NomicFoundation#763 --------- Co-authored-by: John Kane <[email protected]>
We need two tests, one to cover the standard HH node behaviour and one to cover the anvil behaviour of returning a null rather than a boolean.
We are attempting to use `any` and testing casting less. remove superfluous type cast
…-create2 Fix: handle anvil `hardhat_setBalance` response for create2
…rcular-imports Handle circular imports in verify loop
The Solidity grammar suggests that the first character of an identifier must be a letter. It is arguable therefore, that we should do that for the args list, but I think this increment in precision is enough. See https://docs.soliditylang.org/en/v0.8.26/grammar.html#a4.SolidityLexer.Identifier
…oad-brackets Adjust regex to handle square brackets
Add PR review notifications workflows
|
I actually don't think this is needed at all. We have access to the chain ID, either by querying the network or via the custom one configured in hardhat config. All we need to do is pass the existing chain ID into the viem functions as well. No need for a new parameter. @kanej |
|
Agreed with @zoeyTM. Can you explain the motivation behind a new param? Is it because of a type-level limitation? |
zoeyTM
force-pushed
the
development
branch
2 times, most recently
from
6f5ec1c
to
1675490
Compare
I originally considered defining the custom chain inside the deploy function automatically if the chain id doesn't match a supported viem chain. But you have to make assumptions about native currency name, symbol, and decimals. They're required params when defining a viem chain. https://viem.sh/docs/chains/introduction#custom-chains EDIT: also I figured it should support functionality similar to the other viem hardhat functions (getPublicClient, getWalletClients, etc). They solve this problem with an optional chain parameter |
I think this functionality would be better served via extending hardhat config, adding the necessary fields to custom chains there, then pulling the info from |
And generate the custom chain internally if it's defined in the hardhat config? I can do it this way, I just want to make sure I understand how ya'll want it done before I get started |
see #782