Hyperlane VS Code

This project greatly simplifies the developer experience when deploying Hyperlane to new chains. It provides a VS Code extension which gives insight into the status of Hyperlane availability on any number of chain IDs at once. For chains where Hyperlane is not yet available, users can use the VS Code extension to directly deploy Hyperlane smart contracts to those chains. This project also provides a web application for configuring Hyperlane deployments for this purpose.

The first step is to install the extension. You can find the extension on the VS Code Marketplace by searching for "Hyperlane VS Code". After installing the extension, you should go into VS Code's Settings > Extensions > Hyperlane VS Code, and configure a directory for where you want config files to be located, and a private key for deployments.

Next, simply open any .ts or .js file, and any line which has a chain ID in the format of "chainId: <id>" will be highlighted. For example, Hardhat project configuration files may have chain IDs for each of the chains that a user interacts with.

When hovering over a chain ID, the extension will use both the Hyperlane SDK and the artifacts directory (located in the config dir) to determine if Hyperlane is available on that chain.

If it is available through the Hyperlane SDK, the details of that chain are shown, such as block explorer URLs (with clickable links) and RPC URLs.

If it is not available, the tool looks in the config files to determine if that specific chain ID is ready for deployment. If not, it will provide two options:

1. Generate sample config - this creates example config files similar to the ones in hyperlane-deploy, but as JSON files.
2. Configure Hyperlane deployment - this opens a web browser to https://hyperlane-vscode.vercel.app/ , which is a web app to help with creating Hyperlane config files. The web app provides inputs for fields needed in the "chains" and "multisig_ism" config files. When the user is done inputting info, they can click "Save JSON Config" to save "chains.json" and "multisig_ism.json" -- these should be placed in the config directory specified in the VS Code settings under the Hyperlane extension.

When config files have been created, users will have the option to deploy Hyperlane contracts to the chain ID that was highlighted and clicked on. This deployment treats the highlighted chain ID as the intended local chain, and considers all other chain IDs from the "chains" config file as remote chains.

After the deployment of all contracts has completed for the new chain, a popup will notify the user about this, and the chainId highlighting and hover information will be updated to show the new availability, along with important Hyperlane contract addresses such as the Mailbox address.

With the information and convenient deployments provided by our extension, users can easily see where Hyperlane is available and permissionlessly deploy Hyperlane to any additional chains.

This project contains the following components:

• A Visual Studio Code extension that makes use of the Language Server Protocol to provide insights into Hyperlane availability on any referenced chain and allows for easy deployments where Hyperlane is not yet available.
• A web application built with React, for configuring Hyperlane deployments such as chain IDs, chain names, RPC URLs, and validator addresses. The output of the web app is downloaded as JSON files that are used by the VS Code extension for deploying Hyperlane contracts on any chain.

Notably, the VS Code extension makes direct use of two Hyperlane projects: the Hyperlane SDK to determine which public chains are supported, and directly embeds a modified and reduced copy of hyperlane-deploy to perform deployments.

Since we use the published Hyperlane SDK library for determining supported chains, we will be able to easily get updates when new chains are officially supported.

On the other hand, embedding hyperlane-deploy code itself was a large and difficult task, because of its strong reliance on its config files. The embedded hyperlane-deploy code was modified throughout to use config files at runtime (instead of build time), and reads them in JSON format. We took this design decision so that users do not need to install anything other than the VS Code extension itself, and that extension can deploy contracts directly. The JSON format was also chosen to avoid tight coupling of logic and configuration, which was a problem that we identified in the official hyperlane-deploy.

Another problem that we encountered was we were using two local chains for testing, and on first run, we are only deploying Hyperlane to one of them. This caused the writing of agent config files to encounter an error, because the other local chain did not have Hyperlane (and therefore did not have a Mailbox address) available. We noticed that hyperlane-deploy's solution was to not write the agent files on first deploy, however this was not an acceptable solution for a deployment tool such as ours. It needed to be able to handle edge cases such as this. Our solution was to only write agent config files for the chains where Hyperlane was available. This allowed us to successfully write the relevant files all the time.