0xproject / tools

---

0x is an open protocol that facilitates trustless, low friction exchange of Ethereum-based assets. For more information on how it works, check out the 0x protocol specification.

This repository is a monorepo including the 0x protocol smart contracts and numerous developer tools. Each public sub-package is independently published to NPM.

Packages

Visit our developer portal for a comprehensive list of core & community maintained packages. All packages maintained with this monorepo are listed below.

TypeScript/Javascript Packages

Ethereum tooling

Package	Version	Description
@0x/web3-wrapper		An Ethereum JSON RPC client
@0x/sol-compiler		A wrapper around solc-js that adds smart re-compilation, ability to compile an entire project, Solidity version specific compilation, standard input description support and much more.
@0x/sol-coverage		A solidity test coverage tool
@0x/sol-profiler		A solidity gas cost profiler
@0x/sol-trace		A solidity stack trace tool
@0x/sol-resolver		Import resolver for smart contracts dependencies
@0x/subproviders		Web3 provider middlewares (e.g. LedgerSubprovider)
@0x/sol-doc		Solidity documentation generator

Utilities

Package	Version	Description
@0x/abi-gen		Tool to generate TS wrappers from smart contract ABIs
@0x/tslint-config		Custom TSLint rules used by the 0x core team
@0x/types		Shared type declarations
@0x/typescript-typings		Repository of types for external packages
@0x/utils		Shared utilities
@0x/assert		Type and schema assertions used by our packages
@0x/base-contract		BaseContract used by auto-generated abi-gen wrapper contracts
@0x/dev-utils		Dev utils to be shared across 0x packages

Usage

Node version 6.x or 8.x is required.

Most of the packages require additional typings for external dependencies. You can include those by prepending the @0x/typescript-typings package to your typeRoots config.

"typeRoots": ["node_modules/@0x/typescript-typings/types", "node_modules/@types"],

Contributing

We strongly recommend that the community help us make improvements and determine the future direction of the protocol. To report bugs within this package, please create an issue in this repository.

Read our contribution guidelines.

Install dependencies

Make sure you are using Yarn v1.9.4. To install using brew:

brew install [email protected]

Then install dependencies

yarn install

You will also need to have Python 3 installed, in order to build and run the tests of abi-gen's command-line interface, which is integrated with the yarn build, yarn test, and yarn lint commands described below. More specifically, your local pip should resolve to the Python 3 version of pip, not a Python 2.x version.

Build

To build all packages:

yarn build

To build a specific package:

PKG=@0x/web3-wrapper yarn build

To build all contracts packages:

yarn build:contracts

Watch

To re-build all packages on change:

yarn watch

To watch a specific package and all it's dependent packages:

PKG=[NPM_PACKAGE_NAME] yarn watch

e.g
PKG=@0x/web3-wrapper yarn watch

Clean

Clean all packages:

yarn clean

Clean a specific package

PKG=0x.js yarn clean

Rebuild

To re-build (clean & build) all packages:

yarn rebuild

To re-build (clean & build) a specific package & it's deps:

PKG=0x.js yarn rebuild

Lint

Lint all packages:

yarn lint

Lint a specific package:

PKG=0x.js yarn lint

Run Tests

Run all tests:

yarn test

Run a specific package's test:

PKG=@0x/web3-wrapper yarn test

Run all contracts packages tests:

yarn test:contracts

tools's Issues

sol-compiler not able to import remote dependencies

Expected Behavior

A contract imported with statement

import "@uniswap/v3-periphery/contracts/interfaces/IPoolInitializer.sol";

should not return an error

Current Behavior

error AUniswapV3NPM.sol:26:1: ParserError: Source "0֦swap/v3-periphery/contracts/interfaces/IPoolInitializer.sol" not found: Callback not supported.

Possible Solution

Steps to Reproduce (for bugs)

1. add import statement as described above
2. compile a contract that uses the import
3. compilation will result in an error

Context

trying to import external contracts as .dep instead of having to manually add them to the package external deps.

Your Environment

| Package | Version |
| @0x/sol-compiler: | 4.7.6 |

| Network |
| testrpc |
| NAME |

0x/subproviders Trezor EIP-712 update

According to the implementation here https://github.com/0xProject/tools/blob/development/subproviders/src/subproviders/trezor.ts#L157 eth_signTypedData are not supported by Trezor.

However, Trezor supports it now (it's really recent tho)
Implementation : trezor/connect@08e4382
Doc: https://github.com/trezor/connect/blob/develop/docs/methods/ethereumSignTypedData.md

Do you have any plan to add this to the TrezorSubprovider ?

Thank you.

Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

./node_modules/@0x/utils/node_modules/ethers/dist/ethers.min.js
Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

Started to see this on our Next.js project when moving from the umbrella package to the individual packages.

@0x/contracts-gen copy issue

Expected Behavior

"@0x/contracts-gen copy" should pull the contracts list from compiler.json file, when specified, and correctly pop the .sol extension at the end of the file name

Current Behavior

Returns the following error (Migrations.sol is the first contract in the compiler.json contracts list) when running "contracts-gen copy"
"

contracts-gen copy

{ Error: ENOENT: no such file or directory, copyfile './test/generated-artifacts/Migrations.sol.json' -> './generated-artifacts/Migrations.sol.json'
"

Possible Solution

Steps to Reproduce (for bugs)

1. Add a list of contract names (even without .sol extension, sol-compiler will overwrite it with ${name}.sol)
2. run script "sol-compiler copy"

Context

Your Environment

| Package | Version |
| @0x/sol-compiler: | :4.4.1 |

Network
testrpc

@0x/sol-profiler not working with solc 0.7.6

Expected Behavior

@0x/sol-profiler works with solc 0.7.5 but not with 0.7.6.

Here is a reproduction: https://github.com/lcswillems/0x-profiler-error-0.7.6

I get this error:

TypeError: Cannot read property 'split' of undefined
    at Object.parseSourceMap (/mnt/Data/Downloads/dev-tools-truffle-example/node_modules/@0x/sol-tracing-utils/src/source_maps.ts:53:28)
    at TraceCollector.<anonymous> (/mnt/Data/Downloads/dev-tools-truffle-example/node_modules/@0x/sol-tracing-utils/src/trace_collector.ts:106:33)
    at Generator.next (<anonymous>)
    at fulfilled (/mnt/Data/Downloads/dev-tools-truffle-example/node_modules/@0x/sol-tracing-utils/lib/src/trace_collector.js:5:58)

After investigation, it seems the profiler assumes contract artifact contains a field compilerOutput.evm.deployedBytecode.sourceMap which is not the case.

sol-compiler returning an error when downloading multiple solc binaries on CI

Expected Behavior

Compiling different contracts with different solc binaries should not give error, but does as EF has moved link for binaries downloads and previous link is under Github Sites.

Current Behavior

Downloading binaries locally is buggy at first, but ofc once binaries are downloaded, the error is not returned. However, this returns an error each time a cycle like CircleCI is run.

Possible Solution

use most recent link, as already proposed in my PR

Steps to Reproduce (for bugs)

1.
2.
3.

Context

Your Environment

| Package | Version |
| @0x/sol-compiler: | 4.7.6 |

| Network |
| testrpc |
| NAME |

refresh the lockfile to automatically remove the vulnerability introduced in @0x/[email protected]

Hi, @fragosti, I have reported a vulnerability issue in package ethers.

As far as I am aware, vulnerability CVE-2020-28498 detected in package elliptic<6.5.4 is directly referenced by  [email protected], on which your package @0x/[email protected] directly depends. As such, this vulnerability can also affect @0x/[email protected] via the following path:
@0x/[email protected] ➔ [email protected] ➔ [email protected](vulnerable version)

Since ethers has released a new patched version [email protected] to resolve this issue ([email protected]➔[email protected](fix version)), then this vulnerability patch can be automatically propagated into your project only if you update your lockfile. The following is your new dependency path :
@0x/[email protected] ➔ [email protected]➔[email protected](vulnerability fix version).

A warm tip.^_^

Ethereum EIP-1159

ethereum-types needs to include the new gas price values that changed with EIP-1159.

sol-compiler update link for solc binary downloads

tools/sol-compiler/src/utils/compiler.ts

Line 131 in ccea611

const versionList = await fetch('https://ethereum.github.io/solc-bin/bin/list.json');

posibility of a 4.7.5 release with less strict yargs version dependency

Hi, @merklejerk, there is a vulnerability introduced by package mem:

Issue Description

I noticed that a vulnerability is introduced in @0x/[email protected]:
Vulnerability npm:mem:20180117 affects package mem (versions:<4.0.0): https://snyk.io/vuln/npm:mem:20180117
The above vulnerable package is referenced by @0x/[email protected] via:
@0x/[email protected] ➔ [email protected] ➔ [email protected] ➔ [email protected]

Since @0x/[email protected] is referenced by 50 downstream projects (e.g., @chainlink/test-helpers 0.0.7-alpha (latest version), eth-saddle 0.1.25 (latest version), @compound-finance/sol-coverage 4.0.10-alpha.7 (latest version), @chainlink/test-helpers 0.0.7-alpha (latest version), @0x/sol-profiler 4.1.28 (latest version)), the vulnerability npm:mem:20180117 can be propagated into these downstream projects and expose security threats to them via the following package dependency paths:
(1)[email protected] ➔ @compound-finance/[email protected] ➔ @compound-finance/[email protected] ➔ @0x/[email protected] ➔ [email protected] ➔ [email protected] ➔ [email protected]
(2)[email protected] ➔ @0x/[email protected] ➔ [email protected] ➔ [email protected] ➔ [email protected]
......

If @0x/[email protected].* removes the vulnerable package from the above version, then its fixed version can help downstream users decrease their pain.

Given the large number of downstream users, could you help update your package to remove the vulnerability from @0x/[email protected] ?

Fixing suggestions

In @0x/[email protected], maybe you can kindly try to perform the following upgrade :
yargs ^10.0.3 ➔ ^11.1.1;

Note:
[email protected](>=11.1.1 <12.0.0, >=12.0.2) transitively depends on [email protected] which has fixed the vulnerability npm:mem:20180117.

Thank you for your attention to this issue and welcome to share other ways to resolve the issue.^_^