Skip to main content

Dapp Lifecycle

When you're developing a dapp with Cubist, you'll probably need to update and test your on-chain and off-chain code. This page describes how to use Cubist as your app evolves.

Update your Cubist configuration file​

When you update your Cubist configuration---say, to change chains or endpoint locations---some of Cubist's auto-generated files will become stale. This section talks about how to recover from that situation.

Let's imagine, for example, that you've been looking at our cross-chain storage example using JavaScript, and now you want to run StorageReceiver on Avalanche instead of Ethereum. This is easy to do with a couple edits to cubist-config.json. But first, assuming you've already deployed the contracts in your test environment, you will need to clean up stale auto-generated files and restart the Cubist processes. Here's how:

  1. First, run cubist stop to stop all background processes.

  2. Cubist generates files in the build_dir and deploy_dir paths in cubist-config.json. (In our example, these are the build and deploy subdirectories.) build_dir contains auto-generated code, while deploy_dir contains deployment receipts and other metadata. In this case, we will want to delete both directories, e.g., with rm -rf build deploy.

caution

When you delete the receipts in the deploy/ directory, you will no longer be able to interact with the deployed contracts using the Cubist SDK.

During local testing this is fine, but once you're deploying contracts to testnets and mainnets, you should start carefully backing up your deploy/ directory. A good strategy is to check this directory into git so that you can easily recover old files.

  1. Now we are ready to update cubist-config.json, replacing "ethereum" with "avalanche" in two places.

  2. Run npm install or yarn to ensure that all dependencies are up-to-date. (In this example, no changes should be necessary, but it doesn't hurt to double check!)

  3. Finally, we can cubist build, then cubist start, and we're ready to deploy again: npm run deploy 0.

That's it! We've moved our StorageReceiver contract to Avalanche with just a config edit.

Edit your smart contracts​

In this example, let's look at how you'd clean up and re-deploy after editing your on-chain code. As in the prior example, some of Cubist's auto-generated files will become stale, so we'll have to remove them and re-deploy.

This time, let's look at our token bridge example using Rust. Specifically, let's imagine we've already deployed the contract to our test environment and run the simple test code in src/main.rs. Now we want to modify the contract to slightly increase the fee, from a tenth of a percent to a seventh of a percent. Here's how we're going to clean up the stale files, update our contract, and re-deploy:

  1. First, cubist stop.

  2. Next, we're going to remove the build_dir and deploy_dir. (See the above warning about deploy_dir's contents---remember to back up the contents whenever you're not just playing with a local test environment!) In the case of Rust, though, we should also remove the generated Rust files, namely, src/cubist_gen.rs and src/cubist_gen/*. In sum, then, we will want to rm -rf build deploy src/cubist_gen*.

tip

The Rust token bridge example comes with a Makefile that will do the cleanup for you---see Makefile. Assuming you have make installed, running make clean will remove the auto-generated files.

This makefile also defines another target, moreclean, that does a more complete cleanup, including deleting all the intermediate Rust build files. In this case, moreclean isn't necessary, and keeping those intermediate files will make future builds run more quickly.

  1. Now we are ready to edit contracts/TokenSender.sol, computing kept as msg.value / 700 instead of msg.value / 1000 in order to increase the fee to ~0.143%.

  2. Finally, we can cubist build, then cubist start, and we're ready to re-deploy and run a quick test: cargo run. Unfortunately, this will fail because src/main.rs is expecting the fee to be 0.1%!

To fix this, let's carry on to the next example: editing the off-chain code and re-running.

Edit your off-chain code​

At the end of the prior example, cargo run panicked because src/main.rs expects the fee to be 0.1%, causing an assertion failure. In this example, we'll fix that assertion by updating the fee computation in src/main.rs.

In general, if updates to your off-chain code require re-deploying your contract, you're going to have to follow a procedure like the prior example's. When you're only modifying off-chain code and not re-deploying, however, the procedure is much simpler: just edit the code, re-compile, and re-run! In slightly more detail:

  1. To fix src/main.rs, we need to change the FEE_INVERSE constant (near the top of the file) from 1000 to 700, to reflect the fee computation from the prior example's update to contracts/TokenSender.sol. (If you haven't followed the prior example yet, do that first!)

  2. Now cargo run works just fine: the fee amount is computed correctly, so the assertions in src/main.rs succeed.

That's it! As we have seen, when we are only updating off-chain code and those updates don't require us to re-deploy contracts, we can simply edit, compile, and re-run.