Support for Multiple Contracts and Hardhat Networks

[0xD006F00D]

Hi again,

I think supporting multiple contracts is quite important. I rewrote the extension a bit, not sure if the format makes sense so I didn't create a pull request for it. Here as a Gist. I added support for:

• Multiple Contracts (specify string or array in config)
• Multiple Constructors (specify string or array in config)
• Output of Contract Address without Deployment (with --compute)
• Restructure of the task to make it a bit more readable

But I used the same array formatting you had which wouldn't allow individual gas/salt/signer settings for each contract. Maybe having an Array of XDeployConfigs would make more sense, but that would have required a few more changes to the verify subtasks and tests.

Also it would be nice if hardhat networks could be directly referenced or XDeployer can be executed with the --network parameter to specify networks. Hardhat-Deploy also makes use of a tagging system for networks. Maybe XDeployer could just reuse that functionality to select which networks to deploy to.

As I have some custom logic for my contract constructor arguments as the contracts depend on each others I ended up just creating a minimal deploy script and referencing your deployer directly. Maybe somebody can make use of it: Gist

[pcaversaccio]

Hi @0xD006F00D,

thanks for sharing your input and work! So let me quickly elaborate on my design decision of xdeployer; it's really just focused on doing one thing properly: deploying one contract with the same contract address on all selected EVM chains. Some use cases will need multiple contracts with multiple constructors while others want to keep it simple (I've got feedback for so many use cases which loved the simplicity of it). My plugin offers the functionality to exactly implement this. In order to extend this functionality, you can write Hardhat tasks around it (that's exactly why those tasks are so powerful). Having multiple dimensions means you also need to cover properly the error handling for all those cases. When do you stop the deployment if failed, what error triggers what across different contract deployments etc. Some people would like to have even their own deployer contract - fine, you can fork xdeployer and use your own. I cannot and won't cover everything in an agnostic way (some other people wanted automatic Etherscan verification of the deployed contracts e.g.). I love seeing what you have done for your use-case and that's the main reason why I've enabled the Discussions section in this repository. Everyone can share and leverage their own subtasks, custom-deployment scripts etc.

If you think it's worth the time, you could even write your own Hardhat plugin that extends this plugin for your use case!

[0xD006F00D]

Understood, thanks for answering all my questions and all your work

[defido]

@0xD006F00D

Gist

Just to go over your gist, you have setup deploying different constructor arguments & contract code bases/contracts but getting the same single contract address?

Also were you targeting just Arbitrum or multi-chain in this gist? Just wondering for the specific addition.

                 let options = {};
		if (hre.network.name.toLowerCase().indexOf('arbitrum') == -1) {
			options.gasLimit = GASLIMIT;
		}

[0xD006F00D]

Hi Defido,

In my case I am only passing contract addresses in the constructor. As the individual contract addresses are the same across the networks their constructors/bytecode will be the same across all networks too.
If the constructor argument would be changing between networks then the contract address would be different.

Because I know the address for the contract before it's deployed I could actually replace the logic and just have static addresses that I reference in the constructor. But this way it's a bit more convenient when redeploying during testing.

I think I had a gas limit before, but that didn't work with Arbitrum because its gas calculation is a bit different, so I removed it. But in the gist you can see I am actually not using the options object, so its just a leftover. If you want to include it you can add the options object as the last parameter of the create2Deployer.deploy call.