How to make user defined network config url property optional

[Nathan-SL]

We're building a hardhat plugin. How should the plugin be written so that custom networks can omit the url property? Currently, user-defined network configs don't allow omitting the url property and for some special cases, it seems reasonable to have a way to support it as an optional property. Here's the error we get from the validator.

Error HH8: There's one or more errors in your config file:

  * Invalid value undefined for HardhatConfig.networks.networkName.url - Expected a value of type string.
  
    To learn more about Hardhat's configuration, please go to https://hardhat.org/config/

For a config file like below.

const config: HardhatUserConfig = {
    solidity: "0.6.12",
    starknet: {
        dockerizedVersion: "0.9.1",
        network: 'networkName',
    },
    networks: {
        networkName: {
            // url: "http://127.0.0.1:5050",
        }
    }
};

[github-actions]

This issue is also being tracked on Linear.

We use Linear to manage our development process, but we keep the conversations on Github.

LINEAR-ID: 0c6d7400-3e62-4ca4-b055-f80075961d3d

[fvictorio]

I don't think this is doable right now. Maybe we could move that validation after the config is resolved, and that way you could put some dummy urls with extendConfig. But I would like to understand the problem better:

and for some special cases, it seems reasonable to have a way to support it as an optional property

Can you expand on this?

[Nathan-SL]

Yes, If validation happens after config is resolved, providing an empty string inside extendConfig will help us.

Can you expand on this?

On our custom network, integrated-devnet, we intend to enable users to run their programs (by spawning as child processes in different random free ports).

[fvictorio]

That's very interesting.

@alcuadrado what do you think about moving the url validation after resolution?

[Nathan-SL]

Any updates?

[fvictorio]

Hi @Nathan-SL, sorry for not responding before. We decided to go on with that approach. I opened #3323 to track that effort, so I'm going to close this one in favor of that.