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/sphere-stock-export.git - Run
npm install - Setup the credentials by running
Make sure you have SPHERE_PROJECT_KEY, SPHERE_CLIENT_ID, SPHERE_CLIENT_SECRET in your environment variables before running. You can see the credentials generated in
$ ./create_config.sh
config.js - To run all packages tests simply do
grunt test(we use jasmine-node). - Linting and static checks are done by
grunt lint. - You can check the code coverage by running
grunt coverage
Regarding code style like indentation and whitespace, follow the conventions you see used in the source already. Please have a look at this referenced coffeescript styleguide when doing changes to the code.
We also have a coffee linter.
You can lint your code by running grunt lint
Make sure your commit messages follow Angular's commit message format. To make this easy run npm run commit from the root.
docs(contributing): add example of a full commit message
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
BREAKING CHANGE: imagination no longer works
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.
Before submitting a PR, please make sure your code is well unit tested, and build passes on CI We use jasmine-node for testing.
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.
Releasing a new version is completely automated using the Grunt task grunt release.
grunt release // patch release
grunt release:minor // minor release
grunt release:major // major release