To make it easier to contribute to the LoopBack project, we‘ve centralized and opened up the general coding guidelines we’ve been using internally at loopback-contributor-docs. We hope this will help clear up any ambiguity about what we expect and improve turnaround times for landing pull requests from community members.

TL;DR

  • New repository loopback-contributor-docs for open -source contributor information
  • ESLint integration
  • Functional area owners
  • Style guide
  • Git commit message guidelines
  • More public visibility into continuous integration (CI) results
  • Upstream/downstream CI test results

ESLint integration

Code linting is a common practice to help catch common issues ahead of time. ESLint is a popular JavaScript linter which comes with its own set of default rules. We’ve integrated ESLint into all LoopBack projects and normalized our preferred coding styles in our own ESLint configuration available at the eslint-config-loopback repository. In general, we typically follow best practices for general JavaScript code, such as turning on strict mode. Stylistic issues like two space indenting are also chosen based on what is common in the Node.js community. For the full list of rules, see https://github.com/strongloop/eslint-config-loopback/blob/master/eslint.json.

Functional area owners

LoopBack has been growing! This is great news, but it means that there are now so many projects it is becoming too much for everyone on the team to maintain every GitHub repository separately. To address this, the team has decided to split responsibilities into “Functional areas” and assign owners to each area for better focus and attention to domain expertise. These are the project maintainers that will be helping you out with issues across the various LoopBack projects on GitHub.

Style guide

For coding preferences that cannot be caught by ESLint we have a new style guide for edge case scenarios. You can treat this as a living document as styles and updates will change over time, but the basic styles will generally stay the same. Typical cases such as lines that are too long to fit on one line or how to indent multi-line expressions. Please note you will see many inconsistencies at this point time, but feel free to submit a PR with a fix if you notice any source code differing from the conventions outlined.

Git commit messages guidelines

For consistency between all contributors from the community and the LoopBack team, we now have a guideline for Git commit messages. While this sounds basic to Git veterans, you will be surprised how often this comes up. In general, we follow the same rules outlined by @Tim Pope:

  • Capitalized, short (50 chars or less) summary for the commit message.
  • More detailed explanatory text, if necessary.  Wrapped to 72 characters.
  • Write in the imperative tone.

For detailed explanations, see https://github.com/strongloop/loopback-contributor-docs/blob/master/git-commit-messages.md.

More public visibility into continuous integration (CI) test results

In the past, contributors had minimal insight into what was happening with our CI results when submitting pull requests. We’ve managed to rework some of the system to show results for commit and pull request linting (not code linting and tests). More specifically, this means our CI system checks whether the branch is up to date and whether the commit messages are properly formatted. For these types of errors, you can now fix them and update the PRs without having to ask maintainers why.

Upstream/downstream CI test results

Additional changes to the CI system to help turnaround times for reviews include the addition of the upstream/downstream testing. This feature is basically a psychic version of greenkeeper; instead of detecting new versions of your dependencies and testing if they break anything, we test them before they get released. Since downstream testing is done on every pull request, you can expect some CI jobs to take longer to complete than others. Ultimately, this will lead to reduced upstream/downstream breakages for all LoopBack projects in general.

What’s next?

Now that you know how to contribute, please feel free to submit pull requests and continue doing the great work you’ve all been doing to help make LoopBack such a great community.