Danger + Node

#Before we get started

This tutorial continues after “Getting Started” - so you should have seen Danger comment on your PRs.

#“Node App”

A node app could cover anything from an API, to a website, a native app or a hardware project. The rules on these projects tend to come from your larger dev team culture. In Artsy a lot of our rules for applications come from trying to have a similar culture between all projects.

#Assignees

We use a slack bot to let people know when they’ve been assigned to a PR, and so the first rule added to an app is a check that there are assignees to your PR. This is a really simple check:

import { danger, fail, warn } from "danger"

if (!danger.github.pr.assignee) {
  fail("This pull request needs an assignee, and optionally include any reviewers.")
}

The danger.pr object is the JSON provided by GitHub to represent a pull request. So here we’re pulling out the assignee key and validating that anything is inside it.

We can make a small improvement to this rule, by allowing someone to declare that a PR is a “work in progress” Danger can allow the build to pass, but will provide feedback that there is no assignee.

import { danger, fail, warn } from "danger"

if (!danger.github.pr.assignee) {
  const method = danger.github.pr.title.includes("WIP") ? warn : fail
  method("This pull request needs an assignee, and optionally include any reviewers.")
}

Using a function as a variable we can determine whether to fail, or warn based on whether the PR’s title includes the string "WIP".

#PR Messages

In a similar vein, we also want to encourage pull requests as a form of documentation. We can help push people in this direction by not allowing the body of a pull request to be less than a few characters long.

if (danger.github.pr.body.length < 10) {
  fail("This pull request needs a description.")
}

This can be expanded to all sorts of checks for example:

• Making sure every PR references an issue, or JIRA ticket.
• Skipping particular rules based on what someone says inside the message. E.g. “This is a trivial PR.” - in Artsy we allow particular hashtags to suppress feedback from danger.

#Results of CI Processes

Let’s assume you’re using CI for running tests or linters.

script:
  - yarn lint
  - yarn test
  - yarn danger ci

If your tool does not have an extra log file output option, you can look at using tee to copy the text output into a file for later reading ( so you’d change - yarn lint to yarn lint | tee 'linter.log' )

And here’s a really simple check that it contains the word “Failed” and to post the logs into the PR.

import { danger, markdown } from "danger"

import contains from "lodash-contains"
import fs from "fs"

const testFile = "tests-output.log"
const linterOutput = fs.readFileSync(testFile).toString()

if (contains(linterOutput, "Failed")) {
  markdown(`These changes failed to pass the linter:
${linterOutput}
  `)
}

More mature tools may have a JSON output reporter, so you can parse that file and create your own report for danger to post.

If you build something that is a generic wrapper around a specific linting tool, this is a great place to convert that code into a plugin so that anyone can use it. In this case, Danger effectively is a way of moving these messages into the code review session.

For example:

• danger-plugin-jest
• danger-plugin-tslint