Skip to content
This repository has been archived by the owner on Sep 14, 2023. It is now read-only.

devnet <-> prod net toggling story #925

Closed
Tracked by #724
harrysolovay opened this issue Apr 22, 2023 · 0 comments · Fixed by #983
Closed
Tracked by #724

devnet <-> prod net toggling story #925

harrysolovay opened this issue Apr 22, 2023 · 0 comments · Fixed by #983

Comments

@harrysolovay
Copy link
Contributor

harrysolovay commented Apr 22, 2023

How will we allow both Node and Deno users to easily switch––without touching their code––between targeting a development vs. production network?

Currently, one needs to update their code (specifically import specifiers, the chain rune subtype instance name (as of #923) and any references to that name).

- import { Polkadot } from "@capi/polkadot"
+ import { PolkadotDev } from "@capi/polkadot-dev"

- Polkadot.System
+ PolkadotDev.System

This isn't the smoothest of development stories.

I propose that we allow specificity of targets in top-level NetworkConfigs. This would often be used to pair production networks with their devnet counterparts.

import { binary, Config, NetworkConfig } from "capi"

const polkadotDev: NetworkConfig = {
  binary: binary("polkadot", "v0.9.40"),
  chain: "polkadot-dev",
}

export const config: Config = {
  server: "https://capi.dev/",
  networks: {
    polkadotDev,
    polkadot: {
      url: "wss://rpc.polkadot.io/",
      version: "v0.9.40",
      targets: {
        dev: polkadotDev,
      }
    },
  },
}

After syncing this config, one could pass --target dev to Capi's serve command. This would tell the codegen to produce a connection.js reflecting the DevConnection.

This would also open the door for us to validate prod-dev chain feature parity. We could produce console warnings about inconsistencies between the default and target-listed metadata.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant