npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@broxus/locklift-deploy

v1.1.1

Published

Locklift plugin for replicable deployments and easy testing

Downloads

32

Readme

Locklift-deploy

Locklift plugin for deployments management and better testing.

Installation

npm i @broxus/locklift-deploy

And add the following statement to your locklift.config.ts:

import "@broxus/locklift-deploy";
import { Deployments } from "@broxus/locklift-deploy";

declare module "locklift" {
    //@ts-ignore
    export interface Locklift {
        deployments: Deployments<FactorySource>;
    }
}

Quickstart

Before going into the details, let's look at the very basic functionality of locklift-deploy.

locklift-deploy allows you to write deploy scripts in the deploy folder. Each of these files that look as follows will be executed in turn when you execute the following task: locklift -n <networkName> deploy

// deploy/00-deploy-sample.ts
export default async () => {
	const signer = await locklift.keystore.getSigner('0');
    await locklift.deployments.deploy({
            deployConfig: {
                contract: "Sample",
                publicKey: signer.publicKey,
                initParams: { _nonce: locklift.utils.getRandomNonce() },
                constructorParams: { _state: 123 },
                value: locklift.utils.toNano(2)
            },
            deploymentName: "Sample1",// user-defined custom name
        },
        true // enable logs
    );
};

export const tag = "sample1";

Furthermore you can also ensure these scripts are executed in test too by calling await deployments.fixture({include: ['sample1']}) in your test.

This is a huge benefit for testing since you are not required to replicate the deployment procedure in your tests. The tag feature (as seen in the script above) and dependencies will also make your life easier when writing complex deployment procedures.

You can even group deploy scripts in different sub folder and ensure they are executed in their logical order.

Furthermore locklift-deploy can also support a multi-chain settings with multiple deploy folder specific to each network.

Configuration

Extra locklift.config networks' options

deploy

The deploy field override the deploy option and let you define a set of sub-folders containing the deploy scripts to be executed for exact network.

You can thus have one network that will be executing mainnet deployment and other networks deployments, etc.

You could also have a folder that deploy contracts that are live on mainnet but that you need to replicate for your test or local network.

{
  networks: {
    local: {
      deploy: [ 'common/', 'deploy-local/']
    },
    test: {
      deploy: ['common/', 'deploy-test/']
    },
    main: {
      deploy: [ 'deploy-main/' ]
    }
  }
}

In this case, the project structure might look like this:

///
deploy
  ├── deploy-local
  │    └── local-migration-1.ts
  │    └── local-migration-2.ts
  ├── common 
  │    └── common-migration.ts
  ├── deploy-test
  │    └── test-migration.ts
  └── deploy-main
       └── main-migration.ts

How to Deploy Contracts

The deploy command

locklift deploy --network <networkName> [options and flags]

This is a new task that the locklift-deploy adds. As the name suggests it deploys contracts. To be exact it will look for files in the folder deploy or whatever was configured in networks.<networkName>.deploy, see config.

It will scan for files in alphabetical order and execute them in turn.

Options

--tags <tags>: only execute deploy scripts with the given tags (separated by whitespaces) and their dependencies (see more info here about tags and dependencies)

Deploy scripts

The deploy scripts need to be of the following type :

export default async () => {
    // out deployment code
};
export const tag = "sample1";
// optional
export const dependencies = ["sample2", "sample3", "sample4"];

The tags is a list of string that when the deploy command is executed with, the script will be executed. In other word if the deploy command is executed with a tag that does not belong to that script, that script will not be executed unless it is a dependency of a script that does get executed.

The dependencies is a list of tag that will be executed if that script is executed. So if the script is executed, every script whose tag match any of the dependencies will be executed first.

These set of fields allow more flexibility to organize the scripts. You are not limited to alphabetical order and you can even organise deploy script in sub folders.

Deploying and retrieving contracts

Contracts could be easily deployed and saved for further usage via locklift.deployments.deploy function:

// deploy/00-deploy-sample.ts
...
    const signer = (await locklift.keystore.getSigner('0'))!;
    await locklift.deployments.deploy({
            // We use same config for regular locklift factory deployments
            deployConfig: {
                contract: "Sample",
                publicKey: signer.publicKey,
                initParams: { _nonce: locklift.utils.getRandomNonce() },
                constructorParams: { _state: 123 },
                value: locklift.utils.toNano(2)
            },
            deploymentName: "Sample1",// user-defined custom name
        },
        true // enable logs
    );
...

All deploy artifacts are saved to disk now, so that you can get instance of deployed contract via deployments.getContract<ContractAbi>(deploymentName) in any other script:

// 01-use-sample.ts
...
const sample = locklift.deployments.getContract<SampleAbi>("Sample1");
...

Deploying and retrieving accounts

Accounts could be easily deployed and saved for further usage via locklift.deployments.deployAccounts function:

// deploy/02-deploy-account.ts
...
// multiple accounts could be deployed at once
await locklift.deployments.deployAccounts([
      {
         deploymentName: "Deployer", // user-defined custom account name
         signerId: "0", // locklift.keystore.getSigner("0") <- id for getting access to the signer
         accountSettings: {
            type: WalletTypes.EverWallet,
            value: locklift.utils.toNano(2),
         },
      },
   ],
   true // enableLogs
);
...

All deploy artifacts are saved to disk now, so that you can get instance of deployed account via deployments.getAccount(deploymentName) in any other script:

// 03-use-account.ts
...
const deployer = locklift.deployments.getAccount("Deployer").account;
...

Saving external contracts to deployments

Sometimes we want to use contract that was deployed outside of our scripts or was deployed by internal message, for example through some kind of "factory" contract. In such a case we can use low-level method for manual saving deployment artifact:

// save arbitrary contract
locklift.deployments.saveContract({
    deploymentName: "FarmingPool_WEVER-USDT",
    contractName: "FarmingPool",
    address: SOME_ADDRESS
});

// save account
locklift.deployments.saveAccount({
    deploymentName: "Owner",
    signerId: "0", // locklift.keystore.getSigner("0") <--
    address: SOME_ADDRESS,
    accountSettings: {
    	type: WalletTypes.EverWallet,
    	// mSigType: "SafeMultisig/multisig2" for multisig types
	}
});

Testing Deployed Contracts

You can continue using the usual test command:

locklift test

Tests can use the locklift.deployments.fixture(config?: { include?: Array<string>; exclude?: Array<string> }) function to run the deployment. You can also choose what tags you want/don't want to execute if you want.

Here is an example of a test:

describe('Token', () => {
  it('testing 1 2 3', async function () {
    // execute only 'token-deploy' tag
    await locklift.deployments.fixture({include: ['token-deploy']});
    const token = await locklift.deployments.getContract<TokenAbi>('Token'); // Token is available because the fixture was executed
    console.log(token.address);
  });
    
  it('testing 4 5 6', async function () {
    // execute all tags except 'token-deploy'
    await locklift.deployments.fixture({exclude: ['token-deploy']});
    ...
  });
});

Tags and Dependencies

It is possible to execute only specific parts of the deployments with locklift deploy --tags <tags>

Tags represent what the deploy script acts on. In general it will be a single string value, the name of the contract it deploys or modifies.

Then if another deploy script has such tag as a dependency, then when this latter deploy script has a specific tag and that tag is requested, the dependency will be executed first.

Here is an example of two deploy scripts :

export default async () => {
   await locklift.deployments.deployAccounts([
          {
             deploymentName: "Deployer",
             signerId: "0",
             accountSettings: {
                type: WalletTypes.EverWallet,
                value: toNano(10),
             },
          },
       ],
       true // enableLogs
   );
};

export const tag = "create-account";
export default async () => {
    const deployer = locklift.deployments.getAccount("Deployer").account;
    await locklift.deployments.deploy({
            deployConfig: {
                contract: "Sample",
                publicKey: deployer.signer.publicKey,
                initParams: { _nonce: locklift.utils.getRandomNonce() },
                constructorParams: { _state: 123 },
                value: locklift.utils.toNano(2)
            },
            deploymentName: "Sample1",// user-defined custom name
        },
        true // enable logs
    );
};

export const tag = "sample1";
// this ensure the 'create-account' script above is executed first, so `deployments.getAccount('Deployer')` succeeds
export const dependencies = ["create-account"]; 

As you can see the second one depends on the first. This is because the second script depends on a tag that the first script registers as using.