Thoughts on VS Code plugin features / additions

[JoshuaBatty]

I recently came across this video describing the Truffle for VS Code functionality. There's also a write-up here that goes into a bit more depth.

There are some cool ideas in here that we could get inspiration from. Some things like debugging aren't currently possible although there is an issue open here that is tracking the development.

It seems like the general idea for us though is to offer a UI for allowing developers to still interact with forc but without needing to interact with the command line. One way to do this is by harnessing the command pallet, such as what has been starting in #52. Launching fuel-core and having it appear in the UI is interesting. Also being able to right-click on a script file and have a dialog box appear for running the script is also a cool idea.

I'm sure there are many more cool features we could be looking to add. Just wanted to open an issue so we could start discussing what these could be.

[sdankel]

How do people generally run fuel core? Is it typical to keep it running for a long time or to start it to test one thing (like one contract or script) and then kill/restart it?

For the command pallet I'm thinking it'd make sense to have a command for starting fuel-core as a background process and another command for killing the background process. Alternatively, a single command like "Sway: Restart fuel-core" could do both.

It seems like restarting fuel-core would be a common thing since you can only run a given contract through it once.

Is there a use case where someone would want multiple processes of fuel-core running simultaneously?

[sdankel]

It seems like the general idea for us though is to offer a UI for allowing developers to still interact with forc but without needing to interact with the command line.

This makes sense; one way to go about this is to start implementing the most used CLI commands as command pallets. Another approach would be to implement the VSCode UI for all fo the commands available in the typescript SDK, with the assumption that eventually that SDK will offer everything that the forc CLI does. This would be my preference since we'll have more control over formatting the error messages in a useful way.

According to the docs, these are the features currently implemented for the SDK:

• Deploy and call contracts
• Generate contract types with TypeChain
• Build and send transactions
• Encode/decode contract ABI

Which of these would be most useful as part of the VSCode UI?

[adlerjohn]

How do people generally run fuel core?

There's generally two ways to run stuff: through forc (most applicable for forc run on scripts) or through the Rust SDK (most applicable for contract tests).

For the first, the user will want a long-running instance of the fuel-core binary, since they want to first deploy a contract, then run a script against it. However, is isn't great to do manually since most of the time while testing a script, you'll have to restart the node to be able to test the same script a second time. I would actually suggest not even exposing this functionality to the user, and push them towards using the SDK.

If the plugin exposes forc run, then I think it should default to running simulation instead of the actual transaction.

For the SDK, fuel-core can either run in-memory as a temporary instance for a single Rust test block, or as a binary Soon™ (FuelLabs/fuels-rs#355). This is the preferred way of doing things, since you can set up each test with contracts as you want, then any number of scripts.

[sdankel]

If the plugin exposes forc run, then I think it should default to running simulation instead of the actual transaction.

What do you mean by simulation? Is there a way to mock a transaction?

[adlerjohn]

Yes, essentially run the transaction but don't persist its changes. forc run doesn't have this functionality yet, but I think both SDKs do. If you're going down this route then it can be added to forc run.

[adlerjohn]

Ah I knew I saw the functionality somewhere 😂! It's in an open PR: FuelLabs/sway#1845

[sdankel]

Idea: embed the Fuel swaysap wallet in vscode to developers can deploy their contracts to a testnet (or any network) from vscode. They'd be able to see their funds and sign test transactions for contract deployment.

The transaction builder could even be embedded in vscode. I'm doing some research to see what's feasible from a UX perspective.

[adlerjohn]

The SwaySwap wallet is meant as an insecure burner wallet. Handling key material in general is a sensitive operation. I'm more leaning towards integrating calling forc-wallet.

[JoshuaBatty]

+1 Having a nice front-end as part of the VSCode plugin for forc-wallet would be really cool IMO.

[JoshuaBatty]

Ganache's Truffle Suite has a really nice interface for visualizing and working with test wallets. Perhaps we could take some inspiration from that and translate it to a VS Code interface for the plugin?