Please take a moment to review this document in order to make the contribution process easy and effective for everyone involved.
Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue or assessing patches and features.
We now have a central repository for the sdk and our tools. Gradually, we will be migrating all our tools to the repository. Keep an eye on it here
- Clone the repo with
git clone [email protected]:sphereio/customer-import.git
- Run
npm install
- To run all packages unit tests, simply run
npm test
(we use mocha). - To run all integration tests, simply run
npm test:ci
- To run tests in watch mode, use
npm run test:watch
- Linting and static checks are done by
npm lint
. - You can check the code coverage by running
npm run coverage
Regarding code style like indentation and whitespace, follow the conventions you see used in the source already.
You can lint your code by running npm lint
Make sure your commit messages follow the Angular's format, try npm run commit
:
docs(contributing): make the example in contributing guidelines concrete
The example commit message in the contributing.md document is not a concrete example. This is a problem because the
contributor is left to imagine what the commit message should look like
based on a description rather than an example. Fix the
problem by making the example concrete and imperative.
Closes #1
Breaks having an open issue
- Create a topic branch from where you want to base your work.
- Make commits of logical units.
- Make sure you have added the necessary tests for your changes.
When creating a branch. Use the issue number(without the '#') as the prefix and add a short title, like: 1-commit-message-example
We have two categories of labels, one for status and another for type of issue. Please add the relevant labels as needed. When working on an issue, please add the status: in progress label and when you want it to be reviewed. Add the status: in review and it will be reviewed.
We use mocha for unit and integration test. You can use Cucumber for acceptance tests.
To run tests you need to pass the sphere project key in the command line
npm test --projectkey=[<your personal development project key>]
To run coverage, project key is also needed
npm run coverage --projectkey=[<your personal development project key>]
Good pull requests, such as patches, improvements, and new features, are a fantastic help. They should remain focused in scope and avoid containing unrelated commits.
Please ask first if somebody else is already working on this or the core developers think your feature is in-scope for the related package / project. Generally always have a related issue with discussions for whatever you are including.
Please also provide a test plan, i.e. specify how you verified that your addition works.
Please adhere to the coding conventions used throughout a project (indentation, accurate comments, etc.) and any other requirements (such as test coverage).
After submitting a PR, assign yourself the PR and add part of the NodeJS team in the reviewers section.