Better API for Plugin is needed

[wighawag]

Issues across plugins keep popping up and part of it is due to no clear semantic of the HRE's field

example of issues :

• Plugins / tasks cannot dynamically set config.paths.artifacts #1030

Here the issue is that some field are supposed to be static while some are dynamic. it would be great to clearly differentiate between the 2 or even better make sure hardhat always support the dynamic case (which make more interesting plugin possible)

• solidity-coverage hardhat plugin override the network object sc-forks/solidity-coverage#624

This issue arise from the fact that solidity-coverage assume no plugin is accessing the hre.network field before end.
To go around the issue hardhat-deploy which was proviously accessing it at import time, is now wrapping it in a lazyObject.

It would be great if hardhat expose a strict plugin api that resolve this by ensuring plugin can access and transform each field in turn.

We could for example have a hook so plugin can transform the network field. The current hook (extendEnvironment) is probably not that well suited as for example, in the case of coverage it must be triggered on task invocation

I curently do not have a clear way forward in mind, but would be great to get a discussion going among plugin developer to help make hardhat even better

[cgewecke]

Agree this would be really useful. Even just a list of best practices we should all follow would be great to have.

Another place plugins have come into conflict is around wrapping the provider, (example here) ... would love a guide for the best way of doing this.

[alcuadrado]

Thanks for opening this issue, @wighawag! And also for your feedback, @cgewecke! We won't be able to address this super soon, as we are at full capacity keeping up with the upcoming hardforks and solidity changes, but eventually we will.

As Chris mentioned, I think the first step would be to provide some kind of guidelines about what is expected from plugins and what is not. These guidelines will probably discourage things that some plugins are already doing, but that's fine, as this will help us understand the limitations of the plugin system and guide the design of new APIs.

[fvictorio]

I'm going to close this issue in favor of #3491 (about having a better guide for this) and #3492 (for discussing the future of the plugin system in the next major version). Thanks a lot @wighawag and @cgewecke!