Skip to content

Latest commit

 

History

History
133 lines (102 loc) · 6.12 KB

CONTRIBUTING.md

File metadata and controls

133 lines (102 loc) · 6.12 KB
Raw

Contributing

When contributing to this repository, please first discuss the change you wish to make via issue, pull request, 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.

Developer Startup Guide

Runtime

It's recommended you install Node Version Manager for unix systems or windows. While it isn't required we have a minimum node version requirement (look in package.json under the "engines" key) and we can't accept code that does not work on the minimum specified version.

MongoDB Helpers

  • For setting up a cluster to test against we recommend using mtools.
  • For managing installed versions of MongoDB, we recommend using m.

VSCode Setup

If you just want to get formatting and linting working automatically use these settings:

"settings":{
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  },
  "[javascript]": {
    "editor.defaultFormatter": "dbaeumer.vscode-eslint"
  },
  "[typescript]": {
    "editor.defaultFormatter": "dbaeumer.vscode-eslint",
  }
}

Running the tests

  • Start a mongod standalone with our cluster_setup.sh script
    • Usage: ./test/tools/cluster_setup.sh server
  • Run the tests with npm test

Tests FAQ

  • How can I run the tests against more than a standalone?
    • You can use the test/tools/cluster_setup.sh replica_set
    • You can prefix the npm test with a MONGODB_URI environment variable to point the tests to the correct deployment
      • env MONGODB_URI=mongodb://localhost:27017 npm test
    • If you are running against more than a standalone make sure your ulimit settings are in accordance with mongo's recommendations
    • Changing the settings on the latest versions of macos can be tricky read here (unless you know you need it you shouldn't have to do the complicated maxproc steps)
  • How can I run just one test?
    • To run a single test, use mocha's grep flag: npm run test -- -g 'test name'
    • If it's easier you can also isolate tests by adding .only Example: it.only(‘cool test’, function() {})

Commit messages

Please follow the Angular commit style. The format should look something like this (note the blank lines):

<type>(<scope>): <subject>

<body>

NODE-XXXX

If there is a relevant NODE ticket number it should be in the footer section of the Angular style commit.

This helps the team automate HISTORY.md generation. These are the commit types we make use of:

  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation only changes
  • style: Changes that do not affect the meaning of the code (e.g, formatting)
  • refactor: A code change that neither fixes a bug nor adds a feature
  • perf: A code change that improves performance
  • test: Adding missing or correcting existing tests
  • chore: Changes to the build process or auxiliary tools and libraries such as documentation generation

Conventions Guide

Below are some conventions that aren't enforced by any of our tooling but we nonetheless do our best to adhere to:

  • Ensure Promise usage is optional
    • There is a measurable overhead to Promise usage vs callbacks. To support the broadest of driver usage scenarios we maintain an internal callback api while exposing a surface layer Promise API.
  • Disallow export default syntax
    • For our use case it is best if all imports / exports remain named.
  • As of 4.0 all code in src is in Typescript
    • Typescript provides a nice developer experience As a product of using TS we should be using es6 syntax features whenever possible.
  • Errors
    • Error messages should be sentence case, and have no periods at the end.
    • Use driver-specific error types where possible (not just Error, but classes that extend MongoError, e.g. MongoNetworkError)

Pull Request Process

  1. Update the README.md or similar documentation with details of changes you wish to make, if applicable.
  2. Add any appropriate tests.
  3. Make your code or other changes.
  4. Review guidelines such as How to write the perfect pull request, thanks!

Take a look at Github Flow for a more detailed explanation of this process.