Strategy: figure out how the CSLI suite of tools should work #7
Description
It'll be fun finding a strat for this
~ Vadeep
Currently the vision of CSLI is to provide tools that are context-aware of one another, and we're currently using websockets for that.
These are the ones I've thought of so far, but let's keep dreaming, too.
1. Dashboard
Dashboard (most important piece, probably) that lets folks highlight specific transactions and dive into the details they wish to see.
2. REPL
REPL (this is here: https://github.com/csli-tools/repl) — the most important and interesting aspect is that we can give it an --init flag and point to a file. The REPL will basically eval the stuff in there, and we'll have access to that context.
I'm imagining this begetting a new pattern for smart contract developers. Perhaps we can start with the assumption that our REPL cool works best when the developer installs it globally. (npm i -g @csli/repl) This means they could navigate in their terminal to some smart contract, and the REPL would know to look for files to include when it's run there.
Here's what a common smart contract repo might look like. This example just has one smart contract. The diff shows what we might add:
.
├── Cargo.lock
├── Cargo.toml
├── examples
│ └── schema.rs
├── README.md
├── schema
│ ├── config.json
│ ├── execute_msg.json
│ ├── instantiate_msg.json
│ └── query_msg.json
├── src
│ ├── contract.rs
│ ├── error.rs
│ ├── lib.rs
│ ├── msg.rs
│ └── state.rs
└── tests
│ └── integration.rs
+ └── .csli
+ └── init.tsInside the init.ts file, we'd likely see code similar to what I have here: https://gist.github.com/mikedotexe/d32a6aa2f2fd584500268d63aac3d1a1
as you can see this would expose stuff like upload() and height() and allow us to have access to the alice variable, which represents her wallet.
Those two functions are scratching the surface. Let's think through what kind of things a developer writing a smart contract would like to have access to. ALSO, let's plant in our heads the very real possibility that as the developer experience (DevX) tooling improves, there will come a day when a QA person like Stove can actually run through a scenario to debug. For instance, "hey Steve, people are saying that when you play MochiCrawler and switch levels, you lose one of your items if you have 10 items." Someone could run through that…
upload(mochic) where mochic is an exported variable from the init.ts
whale.send(999, alice)
alice.buyItem('stick') x 10
alice.nextLevel()
Something like that.
So the variables and functions we export from the init.ts file(s) would be whatever is most useful for developers debugging.
What is a good base init.ts that can demonstrate this?
CLI
Eventual CLI that uses JavaScript (After decent consideration, I believe we should use oclif)
But we detect if they're trying to use mainnet and say they shouldn't use this cuz it's in JS and supply chain attacks.
To detect this, we could probably scan their selected RPC and see if it matches the registry here:
^ That shows the mainnet RPC list for Stargaze, which is one of the chains in the Cosmos "interchain"
I don't have a great idea of what the key differences between the REPL and the CLI should be, but I believe there are significant users that would need both. But let's think about it, and look at what good CLIs do. I hear that osmosisd is well done, but I haven't used it. (See https://docs.osmosis.zone/developing/tools/osmosisd.html#minimum-requirements)
Overall, how are we going to keep this suite of tools tied together?
Do we have to talk to wasmd/junod/simd for some things, like getting user credentials for signing? That's fine if so, but let's figure that out.
Is the common advice to "install globally, then navigate to your project and run this command" or do we think we should add something as a dependency?
Do we want the dashboard to automatically detect when a new user has done something in a transaction and update a yet-to-be pane highlighting users? Or do we always do this with config files? Or is it both/either and a mode. And if so, is that a priority.
If we start saving config files to ~/.csli/<package> or whatever, what happens if we need to change that structure? How can we migrate to potentially breaking changes in the future? Maybe there's ez middleware? Maybe oclif would already do it for the CLI.
We talked about how the REPL might load it's init.ts file if it happens to see it easily. What about dashboard config? Might there also be project-broni/.csli/dashboard.js that returns some suggestions? Like if your project relies on several cross-contract calls, a config might set the biggest pane in the terminal to be highlighting contracts involved when a transaction is selected.
Speaking of which, should the whole layout of the Terminal be config from the start?
Stuff like that to spur thoughts