Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hardhat Ignition 1.0.0 #579

Open
alcuadrado opened this issue Oct 22, 2023 · 0 comments
Open

Hardhat Ignition 1.0.0 #579

alcuadrado opened this issue Oct 22, 2023 · 0 comments
Labels
type:epic A bigger effort that involves multiple issues and PRs

Comments

@alcuadrado
Copy link
Member

alcuadrado commented Oct 22, 2023

I'm creating this issue to inform users about our top priorities for the first stable version of Hardhat Ignition.

TypeChain support (#156)

Hardhat Ignition should work seamlessly with TypeChain. Currently, if you call ignition.deploy() from one of your tests, it returns objects of type ethers.Contract, instead of taking advantage of TypeChain. This will be fixed soon.

create2 support (#91)

Users should be able to deploy their modules using a create2 factory, without modifying the modules themselves. Using or not create2 should be a config field or command line parameter.

Better ABI validation (#278)

We should validate that every call and deployment receives arguments of the right type. Ideally, this validation should be done at runtime and by the type system.

Viem support (#589)

The current version of Hardhat Ignition only supports ethers v6. We should also support Viem.

End-to-end integration with Wagmi (#202)

We should have a clear story about how Hardhat Ignition should be used with Wagmi, where things work seamlessly, without having to copy artifacts and addresses around.

Lighter deployment artifacts (#599)

We should make our deployment artifacts lighter and friendlier for version control.

There are two things obvious paths forward here:

  1. Make the BuildInfo files lighter. This can be done by not saving their output information.
  2. Journal pruning: We should consider "compressing" the journal by pruning it after successful runs. For example, if a deployment future is executed successfully, we can replace all of its messages with a single one.
@alcuadrado alcuadrado pinned this issue Oct 22, 2023
@alcuadrado alcuadrado added type:epic A bigger effort that involves multiple issues and PRs and removed status:triaging labels Oct 22, 2023
@kanej kanej modified the milestone: Public beta followup Oct 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:epic A bigger effort that involves multiple issues and PRs
Projects
Status: No status
Development

No branches or pull requests

2 participants