The CBPTT is an open-source project. While it was conceived and is maintained by Coinbase, our vision is to have the community actively contribute to the project, but please note the following:

Before submitting any PRs, please take note

This is an open-source project. This means that there are as many different ideas and thoughts on how to code, test and architect as there are contributors. This also means that getting code into production will often take longer than your average closed-source or corporate project and way longer than any project that you run yourself.

All contributions must adhere to the General Coinbase Contribution Guidelines and Code of Conduct

To contribute to the CBPTT, fork the project on GitHub, make your changes and submit them as a PR.

In addition to the general Coinbase contribution guidelines, there are some additional guidelines for the CBPTT specifically.

Product Roadmap

Check the Product Roadmap and see whether your contribution is within the scope of the project. If it is, great! If not, you still have a few options

1. Open a new issue, outlining your proposal / feature-request, and indicate that you are willing to code it up yourself.
2. If your idea sits in Layer 3 or 4 (as defined in the Roadmap), the best approach is actually to start a new project, use the CBPTT as a library, and then open a new issue so that we can link to your project or bot from our documentation.

The following PR types are the most welcome and will almost certainly be merged:

• Bug fixes!
• Unit tests (see notes on tests below)

Coding language

Pull requests must be written in TypeScript. If you’re a Javascript programmer, don’t fret, the learning curve is very flat. TypeScript is a superset of Javascript, but because it is statically typed, whole classes of bugs are eliminated from your code before it reaches us. Since the CBPTT can work with real money, we feel this is a good thing.

Code Style

Make sure your code passes the linting tests before submitting your PR.

We use TSLint for syntax checking. The specific rules we apply are configured in the tslint.json file in the project folder.

To run the linter run

yarn run lint

You can auto-fix many of the more typographic errors, assuming you’ve installed tslint globally by running

tslint -p . --fix

You can also make your life much easier by adding TSlint integration into your editor. WebStorm / IntelliJ for example, auto-fix many errors by running the Reformat-Code command.

Unit tests

We also welcome new tests to help move our test coverage towards 100%.

As with the coding guidelines, we have standardised on some libraries and practices for testing, so here are some testing PR dos and don’ts.

To run the full battery of unit tests run yarn test

To get coverage statistics, run yarn run coverage

Do

• Include tests with your general PRs
• Submit PRs that add new tests to improve test coverage (This is a great way to learn the API and uncover edge cases, BTW)
• Use Mocha BDD syntax (describe, it) for defining tests
• Use the standard assert module for assertions.

Don’t

• Add new testing or assertion libraries as dependencies (e.g. chai, cucumber, etc.)
• Don’t let your unit tests make network calls (Use nock for HTTP request mocking)

Documentation

Document your classes! The API reference documentation is automatically generated by TypeDoc. TypeDoc strips out the comments from files to generate reference documentation. The format is almost identical to JSDoc with a few tweaks; primarily that you needn’t include all the param and return fields because TypeDoc can infer this directly from the code.

PR hygiene

• Try and keep your PRs contained to a single feature or bugfix. It makes them easier to review.

• Do not commit IDE-specific files and metadata. Preferably, don’t add those files to .gitignore either. You can locally ignore files by adding them to the .git/info/exclude file in your local working tree. This file follows the same rules as .gitignore. So for example, to exclude Webstorm metadata without changing the .gitignore file, I could run

$ echo ".idea" >> .git/info/exclude

• If you want to embark on a large-scale refactoring effort, please open an issue first to discuss this. In particular, breaking changes or wide-ranging changes to interfaces are likely to get rejected if they haven’t gone through a preview and discussion first.