You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 14, 2023. It is now read-only.
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.
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.
The text was updated successfully, but these errors were encountered:
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).
This isn't the smoothest of development stories.
I propose that we allow specificity of
targets
in top-levelNetworkConfig
s. This would often be used to pair production networks with their devnet counterparts.After syncing this config, one could pass
--target dev
to Capi'sserve
command. This would tell the codegen to produce aconnection.js
reflecting theDevConnection
.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.
The text was updated successfully, but these errors were encountered: