Interface for Spawning Local Nodes

[harrysolovay]

Continued from #140

In many cases (especially during development / when one has no internet connectivity) it is useful to spawn and interact with a local (potentially-temporary) chain / node. How do we want to approach this?

Ideally, developers can do so as easily as...

import * as C from "../mod.ts";

const node = await C.test.node();

// Interact with `node` (`node.url`)

node.close();

I've mocked out this concept here.

Initial thinking: we can achieve this by bundling in a compiled node (such as that of the substrate-node-template). There are issues with this approach:

• We must compile for different systems, detect those systems and run the correct bin (lots of bloat)
• We may want to reference our own node (with a repo user/name/branch, a project on disk or even a precompiled bin)

How do we enable seamless reference of local chains? What do we cache? What do we want the DXs to be?

[harrysolovay]

@pepoviola –– can we perhaps integrate Zombienet into Capi? Raises some questions about Zombienet's distribution (would like to reference it as a peer dep). In your opinion, how might we want to proceed? #63

[wirednkod]

@pepoviola –– can we perhaps integrate Zombienet into Capi? Raises some questions about Zombienet's distribution (would like to reference it as a peer dep). In your opinion, how might we want to proceed? #63

In order to use Zombienet, one needs to (besides zombienet) download and compile also polkadot.

This could be a nice DX experience but makes either the repo bigger size-wise, or makes the user to rely on internet connectivity. On the other hand, if we add this in our .gitignore, then user can download and then use them without an issue.

[pepoviola]

@pepoviola –– can we perhaps integrate Zombienet into Capi? Raises some questions about Zombienet's distribution (would like to reference it as a peer dep). In your opinion, how might we want to proceed? #63

In order to use Zombienet, one needs to (besides zombienet) download and compile also polkadot.

This could be a nice DX experience but makes either the repo bigger size-wise, or makes the user to rely on internet connectivity. On the other hand, if we add this in our .gitignore, then user can download and then use them without an issue.

Hey @harrysolovay, as @wirednkod says for running the node we also need the compiled version of the node (48M if we use the substrate-node-template) and as you say we need to have multiple versions for each arch. Other approach we can take is using zombienet with containers (podman/k8s) so that way the users can spawn nodes from one of the images we publish but this add a third party tool as requirement and I'm also not sure is the best path we can follow.

Maybe adding a command to zombienet to download the appropriated version of the node-template from the repo is a nice approach, but we can explore other options.

Thanks!

[harrysolovay]

Maybe adding a command to zombienet to download the appropriated version of the node-template from the repo is a nice approach, but we can explore other options.

I quite like this idea. This is the approach taken by the Dprint formatter (one specifies a remote wasm blob containing the language-specific formatting logic).

[harrysolovay]

#296 makes defining an in-JS dev-chain-ctrl interface somewhat irrelevant for now.