You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ignition modules provide significant features (e.g. restartable deploys) but for the simplest case of deploying a single contract, it adds the boilerplate of declaring a module. Can we reduce/eliminate the boiler plate?
This is a design task to answer that question.
We need to support both script/test usage and command line usage.
Questions
How does this interact with module parameters?
Should we ignore the from field (and just rely on --default-sender)
How is the moduleId generated?
Can we rely on the default future id generation for the contract?
How are libraries to be supported? At the command line?
How are constructor args to be handled at the command line?
How does this work with create2?
How do we handle the tracking, from the user perspective of which contracts have been deployed?
Use Cases
Deploy a single Hardhat contract with no constructions args from a script/test by name and get back an ethers contract instance
Deploy a single Hardhat contract with no constructions args from a script/test by name and get back a viem contract instance
Deploy a single Hardhat contract with constructions args from a script/test by name and get back an ethers contract instance
Deploy a single Hardhat contract with constructions args from a script/test by name and get back a viem contract instance
Deploy a single Hardhat contract without constructor args by name from the cli
Deploy a single Hardhat contract with constructor args by name from the cli
Deploy a single contract with no constructor via create2 from script/test
Deploy a single contract resetting the deployment
Approach
From a scripts perspective maybe we enhance the ignition-helpers with a deployContract method:
Ignition modules provide significant features (e.g. restartable deploys) but for the simplest case of deploying a single contract, it adds the boilerplate of declaring a module. Can we reduce/eliminate the boiler plate?
This is a design task to answer that question.
We need to support both script/test usage and command line usage.
Questions
from
field (and just rely on--default-sender
)create2
?Use Cases
ethers
contract instanceviem
contract instanceethers
contract instanceviem
contract instancecreate2
from script/testApproach
From a scripts perspective maybe we enhance the
ignition-helper
s with adeployContract
method:This would be the equivalent of:
In terms of the command line, perhaps we can leverage module parameters with a required property of
constructor-args
or something:npx hardhat ignition deploy-contract MyToken --module-parameters "{\"constructor-args\": [\"COIN\", 10_000]}"
The text was updated successfully, but these errors were encountered: