Update "networks" in config.json to "deployAliases"

[ymekuria]

Closes #217

This PR updates networks to deployAliases in the config.json and throughout the zkApp-cli for clarity. The config.js and deploy.js files were changed to support both cases if either networks or deployAliases are found in the config.json.

[jasongitmail]

Left a comment of an approach that I think would clean it up a bit. Can we also use 'deploy alias' (instead of camel casing) for comments and text displayed to the user?

[jasongitmail]

I think this would be easier to read if values were accessed at config.deployAliases consistently throughout the code. Then lines 45-48 would be updated to check if a deployAliases property exists, and if not, assigns the value of config?.networks to it.

i.e.
if (!config.hasOwnProperty('deployAliases')) config.deployAliases = config?.networks;

Naming is tricky here. We'd benefit from using a consistent pattern to name vars that distinguishes between property name (deployAliasName) and the object value (deployAlias).

[ymekuria]

I agree this approach is more readable, and I updated the code. The downside is if a user has an existing networks in their config.json, an additional deployAliases is added to the config.json after going through the zk config flow. Another option could be to copy the networks config into a new deployAliases config and delete the network config after. I'm hesitant to take this approach though.

[jasongitmail]

The downside is if a user has an existing networks in their config.json, an additional deployAliases is added to the config.json after going through the zk config flow.
But only as a property on the temporary object. If we were writing it back to disk, that'd be a problem, but we don't so I think it's fine.

[ymekuria]

If a user has an existing networks config like this.

{
  "version": 1,
  "networks": {
    "networks-berkeley": {
      "url":   "https://proxy.berkeley.minaexplorer.com/graphql",
      "keyPath": "keys/networks-berkeley.json",
      "fee": ".1"
    }
  }
}

If they run zk config and add the deploy alias berkeley2, the resulting config.json with a networks and deploy aliases is below.

{
  "version": 1,
  "networks": {
    "networks-berkeley": {
      "url": "https://proxy.berkeley.minaexplorer.com/graphql",
      "keyPath": "keys/networks-berkeley.json",
      "fee": ".1"
    },
    "berkeley2": {
      "url": "https://proxy.berkeley.minaexplorer.com/graphql",
      "keyPath": "keys/berkeley2.json",
      "fee": ".1"
    }
  },
  "deployAliases": {
    "networks-berkeley": {
      "url": "https://proxy.berkeley.minaexplorer.com/graphql",
      "keyPath": "keys/networks-berkeley.json",
      "fee": ".1"
    },
    "berkeley2": {
      "url": "https://proxy.berkeley.minaexplorer.com/graphql",
      "keyPath": "keys/berkeley2.json",
      "fee": ".1"
    }
  }
}

[jasongitmail]

Idea: How about when running zk config, we check if networks property exists and replace with deployAliases when writing it to the file, thereby transitioning the config. Then someday in the future (1yr+), we can clean up and remove this code and just assume deployAliases exists and let really, really old ones break. Or we could use the version number, but I kinda like the former.

wdyt?

[ymekuria]

We should take the first approach. That is what I meant when I said this earlier but I didn't communicate it clearly.

Another option could be to copy the networks config into a new deployAliases config and delete the network config after.

[jasongitmail]

sounds good to me!

[jasongitmail]

This looks great!

Left some minor comments. I think there are some places where it can still use deployAliasName when referring to the string name. I marked a few, but there's more--worth a look over.