UNPKG

tlab-trading-toolkit

Version:

A trading toolkit for building advanced trading bots on the GDAX platform

github.com/coinbase/gdax-tt

coinbase/gdax-tt

79 lines (55 loc) • 3.25 kB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
--- title: Contributing keywords: GTT, overview, contributing last_updated: July 14, 2017 tags: [getting_started] summary: "Please contribute to this project. We accept PRs for bugfixes, new features and new exchanges. Please read our contribution guide lines first though." sidebar: gtt_sidebar permalink: gtt_contributing.html folder: gtt toc: true --- The GTT 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. To contribute to the GTT, [fork the project on GitHub](), make your changes and [subit them as a PR](). The community will review and then hopefully merge your changes in, and it will form part of the next release of the GTT. We want this to be a community project, so the GTT should evolve to become what you want it to be. So we will accept pull requests for any and all of the following: * Bug fixes * New components and filters * New exchange support * Documentation * Tutorials * Working trading bot engines (that make use of the GTT, obviously) * Algorithm components * UI components (see the [gtt-ui]() project. Please read and follow the contribution guidelines before you submit. This will smooth the flow for getting your code included in the project. ## Contribution Guidelines Pull requests must be written in [TypeScript](www.typescriptlang.org). 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 GTT 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](https://palantir.github.io/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, autofix many errors by running the Reformat-Code command. ### Unit tests Our goal is to reach >80% for Beta and ultimately 100% test coverage. For this reason we _highly enourage_ including unit tests in your PRs. Our standard test runner is Mocha, and we use the standard `assert` module for assertions. To run the full battery of unit tests run yarn test ### Documentation Document your classes! The API reference documentation is automatically generated by [TypeDoc](http://typedoc.org/). 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 becuase TypeDoc can infer this directly from the code. {% include warning.html content="If you run TypeDoc locally to view your generated documentation, *do not check those changes into your PR*! For one, it adds too much noise to the PR and secondly, we will automatically update the API docs anyway." %}