Allow plugins to provide more artifacts

[wighawag]

Currently hardhat offer a function hre.artifacts.readArtifact (as well as other method in hre.artifacts)
Unfortunately such artifacts field is hardwired at runtime creation with a specific folder and as a read-only field it is not supposed to be modified.

hardhat-deploy (and even builder-deploy before) offer a mechanism for external import of artifacts, it support different format like truffle too. It does so with its own custom function so user can deploy these artifacts.

But since hardhat, as mentioned do not allow plugin to override the canonical way to get artifacts, other plugin that offer new features to artifacts are not aware of hardhat-deploy artifacts, even if they are compatible.

There are different approches to solve this. One approach is to allow plugin to hook into the getArtifact process so plugins can import artifact from other sources, even transforming it to fit hardhat expected format.

This way any plugin that add features to artifacts can access them via a standard mechanism

[fvictorio]

If I'm understanding correctly, you would like to add extra fields to the JSON artifacts, and then be able to consume them, is that correct?

One thing to keep in mind is that if you add fields, the current type of Artifact won't have those extra fields, but that's an easy problem to circumvent.

[wighawag]

It is not about adding extra field to artifacts, but being able for a plugin to add more artifacts, from different sources. And having that reachable to other plugin

hardhat-deploy already offer that feature but these artifacts are not seen by other plugins

[wighawag]

Any plan to support that somehow?

It has resurfaced with my update of hardhat-deploy-ethers (wip) that is now an extension of hardhat-ethers

hardhat-deploy-ethers used to re-write the function of hardhat-ethers but now this is not easily possible, nor recommended (would need to guess any future addition of function)

One of the reason for the re-write was to ensure ethers.getContractFactoryByName would still consider the extra artifacts that hardhat-deploy allow user to provide.

It would be a lot better if somehow plugin could override hre.artifacts directly, this wwould make any plugin using artifacts.readArtifact support the extra artifacts provided.

[rhlsthrm]

I would very much like this feature to be able to use external libraries in my Hardhat project!

[wighawag]

I started to look at implementating it but I am not sure what is the best way forward

Currently the Artifacts object is instantiated synchrnously at the time the HRE is constructed (https://github.com/nomiclabs/hardhat/blob/e5b5041e15908fe81ee7ad5ec984f74f3fde253d/packages/hardhat-core/src/internal/core/runtime-environment.ts#L76). I think the change would probably be a breaking change as the way it is done now, do not allow for async hooks.

Did you start thinking how we could use the task api for that ?

This is to me the last piece needed to make my hardhat-deploy-ethers plugin an extension to hardhat-ethers. It would also open the api to new kind of plugins that can transform or add new artifacts.

On that note, it might be interesting to allow artifacts to belong to a specific network (Without overwriting other). THis would be useful for network like optimism which require a different compiler on their network

[Jack-ZooFiLabs]

Running into this again. Any progress?

[Jack-ZooFiLabs]

@fvictorio / @wighawag

[alcuadrado]

We've discussed this in private and decided that we are ok with adding an api like this one:

// This callback is only called if the built-in artifacts resolution fails, and no other extension was declared before and succeded
extendArtifactsResolution((name: string) => {
   return somehowGetTheArtifactAndAdaptItsFormatIfNecessaryOrUndefinedIfNotFound(name);
})

We'll probably add other ways of loading dependencies artifacts, but this is a good quick way to allow plugins to do it.

Unfortunately we can't prioritize this yet, but are willing to accept a PR implementing it.

[KholdStare]

Hi, I think this should be higher priority. The hardhat ecosystem is missing something to manage deployments, and something like hardhat-deploy is desperately needed. However it's currently a non-starter because without this issue fixed hardhat-deploy is not compatible with other hardhat plugins like hardhat-ether and hardhat-waffle. Users and the hardhat-deploy maintainer @wighawag have to resort to dirty hacks to try and get it working, and it randomly breaks depending on different package managers, package versions and the phase of the moon.

Please consider prioritizing this higher, or at least taking an hour or two to sketch out "the right way" to do it in order for someone else to come in and help out.

[aspiers]

Somehow I only just discovered Hardhat Ignition yesterday, via #381 (comment). I'm not sure if I'm understanding correctly, but I get the impression that Nomic Foundation maybe don't want to spend extra effort supporting hardhat-deploy, since Ignition is the favoured strategic direction.

[KholdStare]

@aspiers I took a look at https://github.com/NomicFoundation/hardhat-ignition , and there haven't been any commits since July 2021. There is only a single release on npm https://www.npmjs.com/package/hardhat-ignition from a year ago.

It seems to me that project is not maintained 🤔 Even if hardhat-ignition is the longterm solution, hardhat-deploy is available now and it would be nice to support the community/ecosystem.

Will comment in the other issue you linked to. Thanks.

[aspiers]

@KholdStare commented on April 1, 2022 2:57 PM:

It seems to me that project is not maintained 🤔

Thanks, hadn't spotted that.

Even if hardhat-ignition is the longterm solution, hardhat-deploy is available now and it would be nice to support the community/ecosystem.

I totally agree. hardhat-deploy is incredibly useful.

[tuler]

I agree this issue should have a higher priority. It will also enable a better integration between hardhat-deploy and hardhat-etherscan.

[fvictorio]

Thanks for the comments folks. We'll discuss this internally and see if we can move this forward on our roadmap.

[wighawag]

Any update on that ?

There is more and more plugin that hardcode dependency on hardhat-ethers and until this issue is resolved this put hardhat-deploy-ethers in a difficult situation

While I do not think these library should hard code libraries like that (As this prevent user to provide their own implementation), it seems to be a trend and this cause typing issue on hardhat-deploy-ethers

see : wighawag/hardhat-deploy-ethers#12
and wighawag/hardhat-deploy-ethers#26

[fvictorio]

Sorry @wighawag, we'll try to prioritize this.

[douglasqian]

+1 running into this as well

[sharp2448]

+1 me too.
It's a pity, can't use hardhat toolbox like that...
Hardhat-deploy is more important for me rn...

[fvictorio]

@sharp2448 you can use hardhat toolbox and hardhat-deploy (or any plugin not included in the toolbox) together

[wighawag]

@fvictorio the issue is that hardhat toolbox hardcode dependencies to hardhat-ethers and this prevent hardhat-deploy-ethers to be used.

hardhat-deploy-ethers could be used if that issue (1040) was solved though

[gitpusha]

Would be really great to have documented support and compatibility between hardhat-toolbox and hardhat-deploy-ethers

I really wanna switch to using hardhat-toolbox by default but I dont wanna say good bye to hardhat-deploy-ethers `ethers.getContract("ContractName")" method, it's way too handy!

[KirchZ]

First of all thanks for your hard work and commitment.

Any progress on this topic? Its pretty annoying not being able to use hardhat-deploy without hardhat-deploy-ethers due to that functionality.

[layinka]

+1 on this

[noyyyy]

Hope that all things go well. For anything stuck, we can discuss it publicly and work together.

[akuter-bc]

+1