Before contributing, please read our code of conduct.
When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.
Please note we have a code of conduct, please follow it in all your interactions with the project.
Make sure you install Yarn so you can run the project locally. This project uses Yarn Workspaces.
git clone [email protected]:ViacomInc/data-point.git
cd data-point
yarn installOnce you are setup, you may run any of the npm scripts available.
To run the unit tests you may run any of the following commands:
# runs all unit tests with test coverage
yarn run test
# runs all unit tests with test coverage and with watch mode
yarn run watchLinting
We are using StandardJs for linting
Programming style
Aside from trying to follow common Javascript best practices we have made an effort to follow a functional programming approach in our codebase, please help us continue with this pattern.
If you are new to Functional programming there is a lot of good documentation out there, but a good introduction is Eric Elliott's Functional Programming Series. You can start with What is Functional Programming and the more in depth Composing Software posts are really good.
Javascript API restrictions
We want DataPoint to be accessible to users from Node 6.x and above, because of this we would like to stick to Node 6 LTS full compatibility without the use of any transpilers.
That said, for asynchronous code please rely on using BlueBird's promise api.
Testing Style
We want DataPoint to maintain 100% test coverage for a few reasons. It ensures the library is working as expected, and it documents the library with clear examples. If we run jest --verbose, we get a nice, readable list of what the library does:
Here are a few tips for organizing your tests:
- Use the
describeblocks to split up logically related tests, and write clear descriptions of what the tests relate to. (See tests in thebase-entityfor an example.) - Break up individual tests to have as few
expects in each test as possible. This way if a singleexpectfails for some reason, it immediately gets narrowed down to the one test that failed. Also whenjestthrows the error it'll write the description string in the console, so we'll be able to read the English description of what failed and not read any code to understand the problem. (See these tests inreducer-herlpers/utilsfor an example.) - Write simple result expectations directly in the test. Use
toMatchSnapshot()if there is a large, complex expected result. - Write tests for both the passing and the failing scenarios of a function. If a function should throw an error in some circumstance, write a test for that condition. Since the thrown error is likely to be a large object, using
toThrowErrorMatchingSnapshot()is a good way to test that there was a thrown error and that the error object/message matches the expectation. For an example, see these tests inentity-hash/factory.
For more ideas when writing tests, check out this article: http://marclittlemore.com/how-to-write-high-quality-unit-tests/
We will only be supporting node 6 and above, please make sure the code you use is supported by this version.
- Fork it
- Create your feature branch
git checkout -b feature/my-new-feature - Commit your changes through
yarn run commit - Push to the branch
git push origin feature/my-new-feature - Create a new Pull Request
Please update the respective README.md files with details of changes to the interface.
All commit messages must use commitizen format to be accepted, to ensure you use this format, only commit through yarn run commit.
If your pull request includes a breaking change, please submit it with a codemod under data-point-codemods that will help users upgrade their codebase.
Breaking changes without a codemod will not be accepted unless a codemod is not viable or does not apply to the specific situation.