Allow the Dashboard host and port to be configurable when using the Dashboard Hardhat Plugin

[kevinbluer]

Issue

When using the Truffle Dashboard Hardhat Plugin, the target host and port are currently hardcoded to the defaults (localhost and 24012 respectively). As highlighted in this conversation this should be made user configurable by allowing users to specifying them in the Hardhat config.

[gnidan]

You know what I just realized... maybe there's a way for this plugin to remove the need for the user to define the dashboard network themselves. Can HH plugins define networks... is that kosher?

Ooh yeah OK I think we should probably read up on how hardhat-foundry works and just emulate that. Nevermind, it doesn't specifically add networks from Foundry to HH. But it does make use of extendConfig, which I think is what we want.

So that being said, I think we should update the plugin to add a "truffle-dashboard" network automatically and manage it entirely. That name is a little long, so users might want to change it to something other than the default, so we should still allow configuration. I'm thinking this:

import { HardhatUserConfig } from "hardhat/config";
import "@nomicfoundation/hardhat-toolbox";
import "@truffle/dashboard-hardhat-plugin";

const config: HardhatUserConfig = {
  // ... rest of hh config ...

  truffle: {
    dashboardNetworkName: "truffle-dashboard"
  }
};

export default config;

I was originally thinking we needed a whole section for Truffle Dashboard, but that would mean we'd have to decide between truffle: { dashboard: { ... } } and "truffle-dashboard": { ... } (neither of which is ideal). And it's clunky.

But! We don't need to add all that configuration if we just assume that the user is configuring Truffle Dashboard via truffle-config.js in their HH project directory. We already have a way to configure Truffle Dashboard, and that's truffle-config.js! We can just have this plugin just do a TruffleConfig.detect() and use the Dashboard configuration automatically from that!

This eliminates support for the case where users want to run a customized truffle dashboard from a different directory, but I'm not sure that's necessary? This path forward just seems too good to pass up with the de-duplication it offers.

The only thing left for the user to configure in hardhat.config.ts is the name of the Dashboard network we add automatically. Neat huh?

[gnidan]

Did some more digging on the above and chatted with @alcuadrado, who confirms the limitation I describe here.

So I really want this sort of thing:

Example hardhat.config.ts

```typescript import { HardhatUserConfig } from "hardhat/config"; import "@nomicfoundation/hardhat-toolbox"; import "@truffle/dashboard-hardhat-plugin"; const config: HardhatUserConfig = { networks: { "truffle-dashboard": { timeout: 60 // override **only** the default timeout in seconds }, // ... rest of HardhatNetworksUserConfig }, truffle: { dashboardNetworkName: "truffle-dashboard" }, // ... rest of HardhatUserConfig ... }; export default config; ```

i.e., the plugin should minimize the configuration options it adds in that truffle namespace. Instead, we should allow people to override the Dashboard network the same way they would override any HTTP network in their Hardhat config. This plugin should then fill in the gaps between Hardhat's defaults and the user-specified network params.

It's worth noting here that the way Hardhat does config is by separating user config from complete config with defaults. It defines types for the HardhatUserConfig (e.g. HttpNetworkUserConfig), where most fields are optional, and it has separate types for the HardhatConfig, where everything is filled in. Key points here:

• Plugins have the chance to read the user-config and modify the config however they want. So we can add a network just fine.
• Hardhat generates the config from the user-config before plugins run. This importantly includes validation.

The problem with my example is that Hardhat does this:

1. Attempt to validate that network with the timeout property.
2. Try to interpret it as a HttpNetworkUserConfig.
3. Observe that url is missing and fail.

Presumably this fails because there's no good default value for Hardhat to use for url in the output HttpNetworkConfig, and Hardhat isn't architected to consult plugins for missing network configurations.

Now, we can add a fresh network just fine, but if we want users to override this Truffle Dashboard network, I can think of two options:

• Force users to supply a blank url: "" property, which the plugin would overwrite, or,
• Completely manage the Dashboard network and have users configure specific properties somewhere outside the usual userConfig.networks[networkName] object.

With the latter option, we're looking at something like this:

Less ideal example hardhat.config.ts

```typescript import { HardhatUserConfig } from "hardhat/config"; import "@nomicfoundation/hardhat-toolbox"; import "@truffle/dashboard-hardhat-plugin"; const config: HardhatUserConfig = { networks: { // ... entire HardhatNetworksUserConfig // !! MUST NOT INCLUDE THE TRUFFLE DASHBOARD NETWORK !! }, truffle: { dashboard: { networkName: "truffle-dashboard", timeout: 60 } }, // ... rest of HardhatUserConfig ... }; export default config; ``` (_I'm back to thinking we need a `truffle: { dashboard: { } }` namespace, but please someone convince me otherwise!_)

Not ideal. I'm thinking this approach is probably still not terrible... it still seems nice for @truffle/dashboard-hardhat-plugin to supply the network config itself.

But... will lots of people want to configure the timeout or other settings? I was going to suggest default to just disable the timeout altogether for this network, but seems like opinions could easily differ for that (and other settings like gasMultiplier). Bit annoying for these settings to live inside this other truffle.dashboard namespace.

As a small consolation, we can control whether the plugin does this network management by adding a truffle.dashboard.manageNetwork: boolean property, so there's a trivial way to offer an "eject button" to the old/plugin-less behavior.

[gnidan]

This is now done!

@truffle/dashboard-hardhat-plugin supports customization starting in v0.2.0 of that package.