Add blurbs to docs

docs/guides/faq.html.md

@@ -3,18 +3,27 @@ title: FAQ
 subtitle: Frequently Asked Questions
 layout: guide_js
 order: 3
+blurb: Common questions that come up in our GitHub issues.
 ---
 
 ## Can Danger comment inside a file on an PR?
 
 Not yet, but there is a lot of discussion on [danger-js#77][77].
 
-## My
-
 ## Can I use the same Dangerfile across many repos?
 
 Ish, it's currently quite complex to set up, but work is on-going on [Danger/Peril][peril]. This is a hosted version of Danger which does not need to run on CI. Using Peril you can use Dangerfiles to reply to basically any GitHub webhook type.
 
+## I only want to run Danger for internal contributors
+
+Let's say you run Danger on the same CI service that deploys your code. If that's open source, you don't want to be letting anyone pull out your private env vars. The work around for this is to not simply call Danger on every test run:
+
+```sh
+'[ ! -z $DANGER_GITHUB_API_TOKEN ] && yarn danger || echo "Skipping Danger for External Contributor"'
+```
+
+This ensures that Danger only runs when you have the environment variables set up to run. This is how Danger works for a lot of the open source mobile projects in Artsy.
+
 ## I want to help influence Danger's direction
 
 We'd recommend first becoming acquainted with the [VISION.md][] inside Danger, this is the long-term plan. Then there are two ways to start contributing today:

docs/guides/getting_started.html.md

@@ -3,6 +3,7 @@ title: Getting Started with Danger JS
 subtitle: Getting Started with Danger JS
 layout: guide_js
 order: 0
+blurb: Step one on using Danger in your application. Start here.
 ---
 
 So, you're ready to get set up. 

docs/guides/the_dangerfile.html.md

@@ -3,6 +3,7 @@ title: About the Dangerfile
 subtitle: The Dangerfile
 layout: guide_js
 order: 1
+blurb: Step two on using Danger in your app, how to work with it locally and nuances around async code and working with files.
 ---
 
 ## Writing your Dangerfile

docs/guides/troubleshooting.html.md

@@ -3,19 +3,10 @@ title: Troubleshooting
 subtitle: Troubleshooting
 layout: guide_js
 order: 4
+blurb: Answers to common bugs.
 ---
 
-## I only want to run Danger for internal contributors
-
-Let's say you run Danger on the same CI service that deploys your code. If that's open source, you don't want to be letting anyone pull out your private env vars. The work around for this is to not simply call Danger on every test run:
-
-```sh
-'[ ! -z $DANGER_GITHUB_API_TOKEN ] && yarn danger || echo "Skipping Danger for External Contributor"'
-```
-
-This ensures that Danger only runs when you have the environment variables set up to run. This is how Danger works for a lot of the open source mobile projects in Artsy.
-
-## I'm seeing a lot of Cannot read property 'bind' in my tests
+## I'm seeing a lot of "Cannot read property 'bind'" in my tests
 
 This causes all of your tests to fail.
 

docs/tutorials/dependencies.html.md

@@ -3,6 +3,7 @@ title: Danger + Dependencies
 subtitle: Danger + Dependencies
 layout: guide_js
 order: 2
+blurb: An example of how can you use Danger to keep your dependencies in check.
 ---
 
 ## Before we get started
@@ -38,8 +39,8 @@ This works, and for a while, this is enough. Time passes and you hear about a no
 
 There are two aspects that you consider:
 
-* Keeping track of changes to `dependencies` (for noted dependencies)
-* Reading the lockfile for the dependency (for transitive dependencies)
+-   Keeping track of changes to `dependencies` (for noted dependencies)
+-   Reading the lockfile for the dependency (for transitive dependencies)
 
 ### Keeping track of changes to dependencies
 
@@ -112,15 +113,20 @@ Note the use of `readFileSync`, as Danger is running as a script you'll find it
 
 This should give you an idea on how to understand changes to your `node_modules`, from here you can create any rules you want using a mix of `JSONDiffForFile`, `fs.readFileSync` and `child_process.execSync`. Here are a few ideas to get you started:
 
-* Convert the check for the package and lockfile to use `JSONDiffForFile` so that it only warns on `dependencies` or `devDependencies`.
-* Ensure you never add `@types/[module]` to `dependencies` but only into `devDependencies`.
-* When a new dependency is added, use a web-service like [libraries.io][libs] to describe the module inline.
-* [Parse][yarn-parse] the `yarn.lock` file, to say how many transitive dependencies are added on every new dependency.
-* When a dependency is removed, and no other dependencies are added, do a thumbs up 👍.
+-   Convert the check for the package and lockfile to use `JSONDiffForFile` so that it only warns on `dependencies` or `devDependencies`.
+-   Ensure you never add `@types/[module]` to `dependencies` but only into `devDependencies`.
+-   When a new dependency is added, use a web-service like [libraries.io][libs] to describe the module inline.
+-   [Parse][yarn-parse] the `yarn.lock` file, to say how many transitive dependencies are added on every new dependency.
+-   When a dependency is removed, and no other dependencies are added, do a thumbs up 👍.
 
 [started]: /js/guides/getting_started.html
+
 [lockfile]: https://yarnpkg.com/lang/en/docs/yarn-lock/
-[shrinkwrap]:  https://docs.npmjs.com/cli/shrinkwrap
+
+[shrinkwrap]: https://docs.npmjs.com/cli/shrinkwrap
+
 [danger-why]: https://github.com/danger/danger-js/blob/8fba6e7c301ac3459c2b0b93264bff7256efd8da/dangerfile.ts#L49
+
 [libs]: https://libraries.io
+
 [yarn-parse]: https://www.npmjs.com/package/parse-yarn-lock

docs/tutorials/node-app.html.md

@@ -3,6 +3,7 @@ title: Danger in a Node App
 subtitle: Danger + Node
 layout: guide_js
 order: 0
+blurb: An example where you work in a team on a node app, and some of the common Danger rules for working together.
 ---
 
 ## Before we get started
@@ -71,23 +72,23 @@ If your tool does not have an extra log file output option, you can look at usin
 And here's a really simple check that it contains the word "Failed" and to post the logs into the PR.
 
 ````js
-            import { danger, markdown } from "danger"
+                    import { danger, markdown } from "danger"
 
-            import contains from "lodash-contains"
-            import fs from "fs"
+                    import contains from "lodash-contains"
+                    import fs from "fs"
 
-            const testFile = "tests-output.log"
-            const linterOutput = fs.readFileSync(testFile).toString()
+                    const testFile = "tests-output.log"
+                    const linterOutput = fs.readFileSync(testFile).toString()
 
-            if (contains(linterOutput, "Failed")) {
-              const code = "```"
-              markdown(`These changes failed to pass the linter:
+                    if (contains(linterOutput, "Failed")) {
+                      const code = "```"
+                      markdown(`These changes failed to pass the linter:
 
-            ${code}
-            ${linterOutput}
-            ${code}
-              `)
-            }
+                    ${code}
+                    ${linterOutput}
+                    ${code}
+                      `)
+                    }
 ````
 
 More mature tools may have a JSON output reporter, so you can parse that file and create your own report for danger to post.

docs/tutorials/node-library.html.md

@@ -3,6 +3,7 @@ title: Danger + Node Library
 subtitle: Danger + Node Library
 layout: guide_js
 order: 1
+blurb: An example where you work on an OSS node library, so you're trying to improve overall contributions from light contributors.
 ---
 
 ## Before we get started
@@ -49,7 +50,7 @@ Any dependencies that you use are passed on to all of your library consumers, so
 
 An example from Danger itself, is that we want to ensure the README always shows what CI providers will work by default with Danger. As both the app, and Danger use JavaScript, we can import code from the app and use that to create a new rule.
 
-``` js
+```js
 import { danger, fail, warn } from "danger"
 import contains from "lodash.contains"
 
@@ -66,8 +67,6 @@ if (missing.length) {
 
 Danger also uses a similar check to create our type definition files, if any of the public DSL changes then Danger checks that the type definitions have been updated, and recommends how to do so if not.
 
-### 
-
-* Release PRs
+[deps]: /js/tutorials/dependencies.html
 
-[deps]: AasASDASDASDA
+[started]: /js/guides/getting_started.html

docs/tutorials/typescript.html.md

@@ -3,6 +3,7 @@ title: Danger + TypeScript
 subtitle: Danger + TypeScript
 layout: guide_js
 order: 3
+blurb: Specifics on using Danger with TypeScript.
 ---
 
 ### TypeScript
@@ -14,8 +15,8 @@ then the only thing you need to do is change your Dangerfile to be `dangerfile.t
 
 You'll need to take the following steps for danger to evaluate your `dangerfile.ts`:
 
-* Install the `ts-jest` package - `yarn add ts-jest --dev`
-* Add the following `jest` section to your `package.json`
+-   Install the `ts-jest` package - `yarn add ts-jest --dev`
+-   Add the following `jest` section to your `package.json`
 
 ```json
 {

docs/usage/culture.html.md

@@ -3,6 +3,7 @@ title: Cultural Changes
 subtitle: Cultural Changes
 layout: guide_js
 order: 2
+blurb: Discussing introducing Danger into a team, how you can use it to provide positive feedback and encourage adoption of new rules.
 ---
 
 ## Introducing Danger

docs/usage/extending-danger.html.md

@@ -3,6 +3,7 @@ title: Extending Danger
 subtitle: Plugin creation
 layout: guide_js
 order: 0
+blurb: How to take your rules, and make them accessible to more people by writing a Danger plugin.
 ---
 
 You've built a few rules now, and you think you've wrote something that's useful in a more general sense. So, rather than copy & paste between all your Dangerfiles, it's time to move that code into a plugin.