wighawag / hardhat-deploy-ethers

MIT License
69 stars 25 forks source link

Add custom artifacts source #30

Open fvictorio opened 1 year ago

fvictorio commented 1 year ago

This PR adds the necessary boilerplate for implementing a custom artifacts source. This should allow this plugin to be compatible with hardhat-ethers, as discussed in https://github.com/NomicFoundation/hardhat/issues/1040.

We haven't released the artifacts extension feature in a stable version of Hardhat, but I published a dev version with that feature, so I'm using that version as a dependency here. I also added hardhat-deploy as a peer dependency of this plugin, so that config.paths.deployments can be used when instantiating the artifacts source.

I believe this would be a breaking change. Since this plugin is in a 0.x version, I guess just bumping the minor should be enough.

Let me know if there's something else I can do here!

To-do:

wighawag commented 1 year ago

Hey @fvictorio thanks for the PR

For my use case, I just need the artifact search operation to first call hre.deployments.getArtifact and fallback on hardhat's normal artifact search flow, if no artifact is returned from hre.deployments.getArtifact

In current hardhat-deploy-ethers I do the following : https://github.com/wighawag/hardhat-deploy-ethers/blob/71f02668b1fdb875e3552dc5a3020564ec5bebc1/src/internal/helpers.ts#L47-L56

How would I be able to do a similar thing with that boilerplate. IN particular how can I call back into the default ArtifactSource ?

wighawag commented 1 year ago

I suppose I cannot just call `` as this would cause an infinite recursion, no ?

also another question :

can I call extendArtifact inside extendEnvironment ? I am asking because I need access to the hre