Before submitting your contribution, please make sure to take a moment and read through the following guidelines:
- Pull Request Guidelines
- Development Setup
- Scripts
- Project Structure
- Contributing Trade Strategy
- Contributing Exchange API Support
- Contributing Tests
-
The
master
branch is a snapshot of the latest stable release. All development should be done in dedicated branches. Do not submit PRs against themaster
branch. -
The
dev
branch is a current development version -
Checkout a topic branch from a base branch, e. g.
dev
, and merge back against that branch -
If adding a new feature, consider to add accompanying test case
-
It's OK to have multiple small commits as you work on the PR — GitHub can automatically squash them before merging
-
Make sure tests pass
-
Commit messages must follow the commit message convention. Commit messages are automatically validated before commit (by invoking Git Hooks via husky).
-
No need to worry about code style as long as you have installed the dev dependencies — modified files are automatically formatted with Prettier on commit (by invoking Git Hooks via husky)
You will need Node.js version 16+.
After cloning the repo, run:
npm i # install the dependencies of the project
A high level overview of tools used:
The lint
script runs linter.
# lint files
$ npm run lint
# fix linter errors
$ npm run lint:fix
The test
script simply calls the jest
binary, so all Jest CLI Options can be used. Some examples:
# run all tests
$ npm run test
# run all tests under the runtime-core package
$ npm run test -- runtime-core
# run tests in a specific file
$ npm run test -- fileName
# run a specific test in a specific file
$ npm run test -- fileName -t 'test name'
It's a stub.
It's a stub.
It's a stub.
Unit tests are collocated with the code being tested inside directories named tests
. Consult the Jest docs and existing test cases for how to write new test specs. Here are some additional guidelines:
-
Use the minimal API needed for a test case. For example, if a test can be written without involving the reactivity system or a component, it should be written so. This limits the test's exposure to changes in unrelated parts and makes it more stable.
-
Only use platform-specific runtimes if the test is asserting platform-specific behavior.