Migration to Hardhat v3

[carletex]

Creating this draft so we can start tinkering & discussing:

For now:

• Installed new deps (removed old ones)
• Updated README with new NodeJS requirement (we might need to update in docs, etc)
• yarn chain working
• yarn deploy working
  • Using Ignition. Let's see if we don't need hardhat-deploy anymore (also available for HHv3)
  • Missing:
    • inheritedFunctions
    • deployedOnBlock

ToDo (will be adding more):

• Fix GitHub lint workflow
• Create new keystore system (move to custom one => hardhat-keystore / config Variables)
• Make yarn deploy more generic. Before it deployed everything / tag-based. Now only the specified conttract.
• --network for deploy (+ config networks on hardhat.config)
• Verify / Etherscan API key
• Tests (default should be solidity, TS or both?)
• Mainnet Fork
• TS Generation: get inherited functions + deployed block

Known Issues:

• If I deploy, make a change to the contract, and deploy again, I get [ YourContract ] Nothing new to deploy based on previous execution stored in ./ignition/deployments/chain-31337

Fixes #1191

[carletex]

Saving this for easier access :D

[carletex]

Went with this solution for now (naming it generic, so people can deploy everything here by default.... since the module path is hardcoded on package.json)

e.g. This works:

export default buildModule("ScaffoldEthDeployModule", m => {
  const yourContract = m.contract("YourContract", ["0x0000000000000000000000000000000000000000"]);
  const yourContract2 = m.contract("YourContract2", ["0x0000000000000000000000000000000000000000"]);

  return { yourContract, yourContract };
});

they say in their docs

You can create multiple modules in a single file, but each must have a unique ID. To deploy a module, you must export it using module.exports = or export default. As a best practice, we suggest maintaining one module per file, naming the file after the module ID.

But I couldn't make it work (creating more modules in the file + exporting both)

---

Note: they also have https://hardhat.org/ignition/docs/guides/scripts, where you can do more "complex" logic (e.g. console.logs of contract read data)

[carletex]

yarn hardhat keystore set DEPLOYER_PRIVATE_KEY

We'd need to abstract this to the user for yarn generate etc.

Also: for the keystore you need a 8 character password. Unless you use the --dev flag, which doesn't ask for a password at all https://hardhat.org/docs/guides/configuration-variables#improving-ux-when-using-keystore-values-during-the-dev-process

[carletex]

I think we can use regular env vars for non-critical data (like this key) and then the keystore (configVariable) for PKs, etc.