Skip to content

Latest commit

 

History

History
91 lines (64 loc) · 3.54 KB

dev-env.md

File metadata and controls

91 lines (64 loc) · 3.54 KB

Our Development Environment

We're using:

These instructions assume you already have standard installations of node, npm, and python3.

Setup

Set up yarn and hardhat, needed for compiling and running tests:

# If needed, install yarn
npm install -g yarn

# Clone this repo
git clone [email protected]:reserve-protocol/protocol.git

# Install pacakges from npm (including Solidity dependencies)
cd protocol
yarn

# Setup git hooks
yarn prepare

# Init a local .env file
cp .env.example .env

You should also setup slither. The Trail of Bits tools require solc-select. Check the installation instructions to ensure you have all prerequisites. Then:

# Install solc-select and slither
pip3 install solc-select slither-analyzer

# Install and use solc version 0.8.9
solc-select install 0.8.9
solc-select use 0.8.9

# Double-check that your slither version is at least 0.8.3!
hash -r && slither --version

Usage

  • Compile: yarn compile
  • Autoformat solidity and typescript: yarn prettier
  • Report compiled contract sizes: yarn size
  • There are many available test sets. A few of the most useful are:
    • Run only fast tests: yarn test:fast
    • Run P0 tests: yarn test:p0
    • Run P1 tests: yarn test:p1
    • Run plugin tests: yarn test:plugins
    • Run integration tests: yarn test:integration
    • Run tests and report test coverage: yarn test:coverage
  • Lint Solidity + Typescript code: yarn lint
  • Run the Slither static checker: yarn slither
  • Run a local mainnet fork devchain: yarn devchain
  • Deploy to devchain: yarn deploy:run --network localhost

Mainnet Forking

The tests located in test/integration will require the Mainnet Forking setup in place. This is done by setting the MAINNET_RPC_URL variable in your local .env. An Alchemy or Ankr node (something with archive data) is needed for Mainnet Forking to properly work. Additional information can be found here.

Pre-push Validation

We use git pre-push validation to ensure that the code in our master branch always lints, compiles, and at least passes our "fast" tests, before we even share it with each other. However, if you're working on a separate branch, and it's more practical to share code with teammates working to a different standard, you can easily comment out or otherwise modify the lines in .husky/pre-push, and commit those along with your branch.

However, ensure that you do not change the value of .husky/pre-push in our shared master branch; this is the appropriate set of validations for sharing code there.

Further Topics

Echidna

We have some tooling for testing with Echidna, but it is specically in fuzz branch of the repo. See that branch and our echidna usage docs

Test Deployment

See our deployment documentation.