Skip to content

Latest commit

 

History

History
91 lines (61 loc) · 4.9 KB

CONTRIBUTING.md

File metadata and controls

91 lines (61 loc) · 4.9 KB
Raw

0x Contribution Guide

We welcome contributions from anyone on the internet and are grateful for even the smallest contributions. This document will help get you setup to start contributing back to 0x.

Getting started

  1. Fork 0xproject/0x-tools
  2. Clone your fork
  3. Follow the installation & build steps in the repo's top-level README.
  4. Setup the recommended Development Tooling.
  5. Open a draft PR against the development branch and describe the change you are intending to undertake in the PR description. (see our branch naming conventions)

Before making the PR "Ready for review", make sure:

  • It passes our linter checks (yarn lint)
  • It is properly formatted with Prettier (yarn prettier)
  • It passes our continuous integration tests (See: Enabling code coverage checks on your fork for instructions on getting the submit-coverage test to pass on forks)
  • You've created/updated the corresponding CHANGELOG entries.
  • Your changes have sufficient test coverage (e.g regression tests have been added for bug fixes)

Branch structure

We have two main branches:

  • master represents the most recently released (published on npm) version of the codebase.
  • development represents the current development state of the codebase.

ALL PRs should be opened against development.

Branch names should be prefixed with fix, feature or refactor.

  • e.g fix/missing-import
  • If the PR only edits a single package, add it's name too
    • e.g fix/subproviders/missing-import

CHANGELOGs

At 0x we use Semantic Versioning for all our published packages. If a change you make corresponds to a semver bump, you must modify the package's CHANGELOG.json file accordingly.

Each CHANGELOG entry that corresponds to a published package will have a timestamp. If no entry exists without a timestamp, you must first create a new one:

{
        "version": "1.0.1", <- The updated package version
        "changes": [
            {
                "note": "", <- Describe your change
                "PR": 100 <- Your PR number
            }
        ]
    },

If an entry without a timestamp already exists, this means other changes have been introduced by other collaborators since the last publish. Add your changes to the list of notes and adjust the version if your PR introduces a greater semver change (i.e current changes required a patch bump, but your changes require a major version bump).

Development Tooling

We strongly recommend you use the VSCode text editor since most of our code is written in TypeScript and it offers amazing support for the language.

Linter

We use ESLint to keep our code-style consistent.

Use yarn lint to lint the entire monorepo, and PKG={PACKAGE_NAME} yarn lint to lint a specific package.

Integrate it into your text editor:

Auto-formatter

We use Prettier to auto-format our code. Be sure to either add a text editor integration or a pre-commit hook to properly format your code changes.

If using the Atom text editor, we recommend you install the following packages:

Unenforced coding conventions

A few of our coding conventions are not yet enforced by the linter/auto-formatter. Be careful to follow these conventions in your PR's.

  1. Unused anonymous function parameters should be named with an underscore + number (e.g _1, _2, etc...)
  2. There should be a new-line between methods in a class and between test cases.
  3. If a string literal has the same value in two or more places, it should be a single constant referenced in both places.
  4. Do not import from a project's index.ts (e.g import { Token } from '../src';). Always import from the source file itself.
  5. Generic error variables should be named err instead of e or error.
  6. If you must cast a variable to any - try to type it back as fast as possible. (e.g., const cw = ((zeroEx as any)._contractWrappers as ContractWrappers);). This ensures subsequent code is type-safe.
  7. Our enum conventions coincide with the recommended TypeScript conventions, using capitalized keys, and all-caps snake-case values. Eg GetStats = 'GET_STATS'
  8. All public, exported methods/functions/classes must have associated Javadoc-style comments.