diff --git a/.github/issue_template.md b/.github/issue_template.md
index 52b3a8906eb89704e2caaf8ded808dbe32ec4b0d..7924280a83f36cc165a5c97cf6a6c29f50024d18 100644
--- a/.github/issue_template.md
+++ b/.github/issue_template.md
@@ -10,15 +10,15 @@
 
 #### This is a:
 
-* [ ] Bug report (non-security related)
-* [ ] Feature request
-* [ ] I'm not sure which of those it is
+- [ ] Bug report (non-security related)
+- [ ] Feature request
+- [ ] I'm not sure which of those it is
 
 #### I'm using:
 
-* [ ] The Renovate GitHub App
-* [ ] Self-hosted GitHub
-* [ ] Self-hosted GitLab
-* [ ] Self-hosted VSTS
+- [ ] The Renovate GitHub App
+- [ ] Self-hosted GitHub
+- [ ] Self-hosted GitLab
+- [ ] Self-hosted VSTS
 
 #### Please describe the issue:
diff --git a/docs/adding-a-package-manager.md b/docs/adding-a-package-manager.md
index 727b8b5ac8da67945a021c53b35b9aee7f87f45c..a1797aaba5112faf09d2cca0b4a66f21c41b6b7d 100644
--- a/docs/adding-a-package-manager.md
+++ b/docs/adding-a-package-manager.md
@@ -49,9 +49,9 @@ For most managers, it is not necessary.
 
 This function is essential. It takes a file content and returns an array of detected/extracted dependencies, including:
 
-* dependency name
-* dependency type (e.g. dependencies, devDependencies, etc)
-* currentVersion
+- dependency name
+- dependency type (e.g. dependencies, devDependencies, etc)
+- currentVersion
 
 The fields returned here can be customised to suit the package manager, e.g. Docker uses `currentFrom`
 
diff --git a/docs/configuration.md b/docs/configuration.md
index 7ac65194a54db484c0942923f4c7a50766c19277..de71d48a2f8e572319f3357c244eaab044c46504 100644
--- a/docs/configuration.md
+++ b/docs/configuration.md
@@ -4,11 +4,11 @@
 
 Configuration is supported via any or all of the below:
 
-* Configuration file
-* Environment
-* CLI
-* `renovate.json`, `.renovaterc.json`, or `.renovaterc` in target repository
-* `renovate` field of `package.json` in target repository
+- Configuration file
+- Environment
+- CLI
+- `renovate.json`, `.renovaterc.json`, or `.renovaterc` in target repository
+- `renovate` field of `package.json` in target repository
 
 The above are listed in reverse order of preference. i.e. `package.json`
 settings will override `renovate.json` settings, CLI, which overrides env, which
diff --git a/docs/design-decisions.md b/docs/design-decisions.md
index 80e57a0cf4af57b560cfd2ee6a6c255f9ad07363..2cf17ac13cd7b6989c47ee18ecb46fac5e6effe3 100644
--- a/docs/design-decisions.md
+++ b/docs/design-decisions.md
@@ -21,8 +21,8 @@ all operations are performed via the API.
 The script current processes repositories, package files, and dependencies
 within them all synchronously.
 
-* Greatly reduces chance of hitting simultaneous API rate limits
-* Simplifies logging
+- Greatly reduces chance of hitting simultaneous API rate limits
+- Simplifies logging
 
 Note: Initial queries to NPM are done in parallel.
 
@@ -67,11 +67,11 @@ are available. For example if the current example is 1.6.0 and upgrades to 1.7.0
 and 2.0.0 exist, then `renovate` will raise PRs for both the 1.x upgrade(s) and
 2.x upgrade(s).
 
-* It's often the case that projects can't upgrade major dependency versions
+- It's often the case that projects can't upgrade major dependency versions
   immediately.
-* It's also often the case that previous major versions continue receiving Minor
+- It's also often the case that previous major versions continue receiving Minor
   or Patch updates.
-* Projects should get Minor and Patch updates for their current Major release
+- Projects should get Minor and Patch updates for their current Major release
   even if a new Major release exists
 
 This can be overridden via the config option `separateMajorMinor`.
@@ -81,8 +81,8 @@ This can be overridden via the config option `separateMajorMinor`.
 Branches are named like `renovate/webpack-1.x` instead of
 `renovate/webpack-1.2.0`.
 
-* Branches often receive updates (e.g. new patches) before they're merged.
-* Naming the branch like `1.x` means its name still names sense if a `1.2.1`
+- Branches often receive updates (e.g. new patches) before they're merged.
+- Naming the branch like `1.x` means its name still names sense if a `1.2.1`
   release happens
 
 Note: Branch names are configurable using string templates.
@@ -123,6 +123,6 @@ Alternatively, consider using a Configuration File.
 
 Renovate uses the following convention for log levels:
 
-* logger.error should only be used for problems that are likely to be a Renovate bug or require Renovate improvements. These are the types of errors that Renovate administrators should be alerted to immediately
-* logger.warn should be used for problems that might be a Renovate problem so should be checked periodically in batches
-* For _user_ problems (e.g. configuration errors), these should not warn or error on the server side and instead use logger.info
+- logger.error should only be used for problems that are likely to be a Renovate bug or require Renovate improvements. These are the types of errors that Renovate administrators should be alerted to immediately
+- logger.warn should be used for problems that might be a Renovate problem so should be checked periodically in batches
+- For _user_ problems (e.g. configuration errors), these should not warn or error on the server side and instead use logger.info
diff --git a/docs/shareable-configs.md b/docs/shareable-configs.md
index ba3552fea51718325131492a52e344382ed87eb9..80df39d1c550cf01230c2eeb7e5258d429c52a84 100644
--- a/docs/shareable-configs.md
+++ b/docs/shareable-configs.md
@@ -3,26 +3,26 @@
 Renovate uses the term "presets" to refer to shareable config snippets, similar
 to eslint. Unlike eslint though:
 
-* Presets may be as small as a list of package names, or as large as a full
+- Presets may be as small as a list of package names, or as large as a full
   config
-* Shared config files can contain many presets
+- Shared config files can contain many presets
 
 ## Preset config URIs
 
 In human-understandable form, the rules are:
 
-* A full preset URI consists of package name, preset name, and preset
+- A full preset URI consists of package name, preset name, and preset
   parameters, such as `package:preset(param)`
-* If a package scope is specified and no package, then the package name is
+- If a package scope is specified and no package, then the package name is
   assumed to be `renovate-config`, e.g. `@rarkins:webapp` is expanded to
   `@rarkins/renovate-config:webapp`
-* If a non-scoped package is specified then it is assumed to have prefix
+- If a non-scoped package is specified then it is assumed to have prefix
   `renovate-config-`. e.g. `rarkins:webapp` is expanded to
   `renovate-config-rarkins:webapp`
-* If a package name is specified and no preset name, then `default` is assumed,
+- If a package name is specified and no preset name, then `default` is assumed,
   e.g. `@rarkins` expands in full to `@rarkins/renovate-config:default` and
   `rarkins` expands in full to `renovate-config-rarkins:default`
-* There is a special "default" namespace where no package name is necessary.
+- There is a special "default" namespace where no package name is necessary.
   e.g. `:webapp` (not the leading `:`) expands to
   `renovate-config-default:webapp`
 
diff --git a/package.json b/package.json
index 91b5e10b8006229b03c78921875165ac065a6d96..caac63ac87030dc5f558666a3e5c216bd7114f24 100644
--- a/package.json
+++ b/package.json
@@ -114,7 +114,7 @@
     "jest": "23.0.1",
     "mockdate": "2.0.2",
     "nock": "9.2.6",
-    "prettier": "1.12.1",
+    "prettier": "1.13.0",
     "semantic-release": "15.5.0"
   },
   "files": [
diff --git a/readme.md b/readme.md
index baef38716dd34ee44313a6cde26998966b1b49cc..8a024c4790ea8149204ae40468d0fe086e0b9d69 100644
--- a/readme.md
+++ b/readme.md
@@ -11,14 +11,14 @@ Automated dependency updates. Flexible, so you don't need to be.
 
 ## Why Use Renovate?
 
-* Receive automated Pull Requests whenever dependencies need updating. Or whenever you schedule it for.
-* Renovate discovers and processes all dependency files in a repository (e.g. supports
+- Receive automated Pull Requests whenever dependencies need updating. Or whenever you schedule it for.
+- Renovate discovers and processes all dependency files in a repository (e.g. supports
   monorepo architecture such as lerna or yarn workspaces)
-* Extremely customisable behaviour via configuration files or within your `package.json`
-* Use eslint-like shared config presets for ease of use and simplifying configuration
-* Update lock files natively in the same commit, including immediately resolving conflicts whenever PRs are merged
-* Supports GitHub, GitLab (APIv4) and VSTS. BitBucket is a WIP.
-* Open source (installable via npm/yarn) so can be self-hosted or used for free via GitHub App
+- Extremely customisable behaviour via configuration files or within your `package.json`
+- Use eslint-like shared config presets for ease of use and simplifying configuration
+- Update lock files natively in the same commit, including immediately resolving conflicts whenever PRs are merged
+- Supports GitHub, GitLab (APIv4) and VSTS. BitBucket is a WIP.
+- Open source (installable via npm/yarn) so can be self-hosted or used for free via GitHub App
 
 ## Who Uses Renovate?
 
@@ -34,10 +34,10 @@ Renovate was released in 2017 and is now widely used in the developer community.
 
 ## The Renovate Approach
 
-* Everyone can benefit from automation, whether it's a little or a lot
-* Renovate should not cause you to change your workflow against your wishes - don't enforce opinions on users
-* All behaviour should be configurable, down to a ridiculous level if desired
-* Autodetect settings wherever possible (to minimise configuration) but always allow overrides
+- Everyone can benefit from automation, whether it's a little or a lot
+- Renovate should not cause you to change your workflow against your wishes - don't enforce opinions on users
+- All behaviour should be configurable, down to a ridiculous level if desired
+- Autodetect settings wherever possible (to minimise configuration) but always allow overrides
 
 ## Using Renovate
 
diff --git a/website/docs/configuration-options.md b/website/docs/configuration-options.md
index 19ef16a0ca9ca94d7196e505bb1941139e14982b..cf0a9859dd61b31ebefa6849d793958cb0343b69 100644
--- a/website/docs/configuration-options.md
+++ b/website/docs/configuration-options.md
@@ -458,9 +458,9 @@ This setting - if enabled - limits Renovate to a maximum of x concurrent PRs ope
 
 This setting tells Renovate when you would like it to raise PRs:
 
-* `immediate` (default): Renovate will create PRs immediately after creating the corresponding branch
-* `not-pending`: Renovate will wait until status checks have completed (passed or failed) before raising the PR
-* `status-success`: Renovate won't raise PRs unless tests pass
+- `immediate` (default): Renovate will create PRs immediately after creating the corresponding branch
+- `not-pending`: Renovate will wait until status checks have completed (passed or failed) before raising the PR
+- `status-success`: Renovate won't raise PRs unless tests pass
 
 Renovate defaults to `immediate` but some like to change to `not-pending`. If you set to immediate, it means you will usually get GitHub notifications that a new PR is available but if you view it immediately then it will still have "pending" tests so you can't take any action. With `not-pending`, it means that when you receive the PR notification, you can see if it passed or failed and take action immediately. Therefore you can customise this setting if you wish to be notified a little later in order to reduce "noise".
 
@@ -490,11 +490,11 @@ The PR title is important for some of Renovate's matching algorithms (e.g. deter
 
 Behaviour:
 
-* `auto` = Renovate decides (this will be done on a manager-by-manager basis)
-* `pin` = convert ranges to exact versions, e.g. `^1.0.0` -> `1.1.0`
-* `bump` = e.g. bump the range even if the new version satisifies the existing range, e.g. `^1.0.0` -> `^1.1.0`
-* `replace` = Replace the range with a newer one if the new version falls outside it, e.g. `^1.0.0` -> `^2.0.0`
-* `widen` = Widen the range with newer one, e.g. `^1.0.0` -> `^1.0.0 || ^2.0.0`
+- `auto` = Renovate decides (this will be done on a manager-by-manager basis)
+- `pin` = convert ranges to exact versions, e.g. `^1.0.0` -> `1.1.0`
+- `bump` = e.g. bump the range even if the new version satisifies the existing range, e.g. `^1.0.0` -> `^1.1.0`
+- `replace` = Replace the range with a newer one if the new version falls outside it, e.g. `^1.0.0` -> `^2.0.0`
+- `widen` = Widen the range with newer one, e.g. `^1.0.0` -> `^1.0.0 || ^2.0.0`
 
 Renovate's "auto" strategy works like this for npm:
 
@@ -522,9 +522,9 @@ If you set it to `false` then that will take precedence - it means Renovate will
 
 By default, Renovate will detect if it has proposed an update to a project before and not propose the same one again. For example the Webpack 3.x case described above. This field lets you customise this behaviour down to a per-package level. For example we override it to `true` in the following cases where branch names and PR titles need to be reused:
 
-* Package groups
-* When pinning versions
-* Lock file maintenance
+- Package groups
+- When pinning versions
+- Lock file maintenance
 
 Typically you shouldn't need to modify this setting.
 
@@ -619,7 +619,7 @@ This feature is added for people migrating from alternative services who are use
 
 Language support is limited to those listed below:
 
-* **Node.js** - [Read our Node.js documentation](https://renovateapp.com/docs/language-support/node#configuring-support-policy)
+- **Node.js** - [Read our Node.js documentation](https://renovateapp.com/docs/language-support/node#configuring-support-policy)
 
 ## timezone
 
diff --git a/website/docs/configure-renovate.md b/website/docs/configure-renovate.md
index e5068152e66ef4de025ae4ed0931da3cb67ad55c..d67d09c094de3ee3d6c90124b430c3904a0d1688 100644
--- a/website/docs/configure-renovate.md
+++ b/website/docs/configure-renovate.md
@@ -31,16 +31,16 @@ Alternatively, if you prefer to use "dot files" then you can add the same JSON c
 
 Most of the settings in the `renovate.json` onboarding configuration are defaults, however usually this configuration file will have some default overrides in it, such as:
 
-* Automatically enabling angular-style semantic commits if your repository uses them
-* Setting `pinVersions` to false for `dependencies` unless your `package.json` file are all `private`
+- Automatically enabling angular-style semantic commits if your repository uses them
+- Setting `pinVersions` to false for `dependencies` unless your `package.json` file are all `private`
 
 ## Common Overrides
 
 Please check the docs on this website for an exhaustive Configuration Reference, however here are some of the most commonly changed (overridden) configuration settings:
 
-* **pinVersions**: By default (with zero config) it's `false` however the `"config:base"` preset overrides it to autodetect.
-* **labels**: Labels to assign to Pull Requests
-* **assignees**: GitHub users to assign the Pull Requests to
+- **pinVersions**: By default (with zero config) it's `false` however the `"config:base"` preset overrides it to autodetect.
+- **labels**: Labels to assign to Pull Requests
+- **assignees**: GitHub users to assign the Pull Requests to
 
 Renovate will update your PR description each time it finds changes.
 
diff --git a/website/docs/data-security.md b/website/docs/data-security.md
index 3835aa94d25fb1f8e8fb96c0c2e7517e38bc5529..93ed36f9f98f7cc45a66723515c9b7d7d6ee4195 100644
--- a/website/docs/data-security.md
+++ b/website/docs/data-security.md
@@ -15,12 +15,12 @@ If you have any suggestions or questions about our security, please contact us a
 
 The most important consideration for GitHub App security is the [Private Key](https://developer.github.com/apps/building-integrations/setting-up-and-registering-github-apps/registering-github-apps/#generating-a-private-key) used to access installations. This key is metaphorically the "key to the kingdom" and is essentially the only thing anybody needs to gain access to all repositories on which the Renovate App has been installed, so we have handled it with great caution:
 
-* The key is not saved to disk _anywhere_. We do not keep a backup of it on any device, thumbdrive, or password manager.
-* The key is saved in one location - as an [AWS EC2 Parameter Store](http://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html) "Secure String"
-* The EC2 instance we run Renovate on gains access to this Secure String using its IAM Role permissions
-* The private key is not exposed/saved to "env" at any time
-* There exists no generated AWS "Access Key" that has permissions to either (a) read from EC2 Parameter Store, or (b) create IAM users or roles with permissions to access the secure string, or (c) create a new EC2 instance that could gain access
-* When the Renovate App runs and decrypts the Private Key, it is stored in memory only as long as necessary to retrieve temporary tokens for each installation, and it is never written to any log
+- The key is not saved to disk _anywhere_. We do not keep a backup of it on any device, thumbdrive, or password manager.
+- The key is saved in one location - as an [AWS EC2 Parameter Store](http://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html) "Secure String"
+- The EC2 instance we run Renovate on gains access to this Secure String using its IAM Role permissions
+- The private key is not exposed/saved to "env" at any time
+- There exists no generated AWS "Access Key" that has permissions to either (a) read from EC2 Parameter Store, or (b) create IAM users or roles with permissions to access the secure string, or (c) create a new EC2 instance that could gain access
+- When the Renovate App runs and decrypts the Private Key, it is stored in memory only as long as necessary to retrieve temporary tokens for each installation, and it is never written to any log
 
 ## App Ownership
 
@@ -30,10 +30,10 @@ We have chosen to assign ownership of the apps to the GitHub organization "`reno
 
 The Renovate App requires the following GitHub Permissions:
 
-* **Read** access to administration and metadata
-* **Write** access to commit statuses
-* **Write** access to issues and pull requests
-* **Write** access to repository content
+- **Read** access to administration and metadata
+- **Write** access to commit statuses
+- **Write** access to issues and pull requests
+- **Write** access to repository content
 
 The "Forking Renovate" App requires only read-only access to repository content because it submits PRs from its own fork of each repository.
 
@@ -43,8 +43,8 @@ We will explain the need for each of these here:
 
 This is necessary so that Renovate can learn enough about the repository to detect settings without manual configuration. As an example, this permission is used so Renovate can detect:
 
-* The merge types allowed in the repository (e.g. merge commit, merge squash, rebase)
-* Whether the repository status checks require Pull Requests to be up-to-date with base branch before merging
+- The merge types allowed in the repository (e.g. merge commit, merge squash, rebase)
+- Whether the repository status checks require Pull Requests to be up-to-date with base branch before merging
 
 ##### **Write** access to commit statuses
 
@@ -82,8 +82,8 @@ Renovate will always be run from the "production" server and the app's credentia
 
 All logs are stored in the AWS Oregon region as described above. We currently log to:
 
-* CloudWatch Logs (30 day retention)
-* S3 (30 day retention)
+- CloudWatch Logs (30 day retention)
+- S3 (30 day retention)
 
 Select metadata (such as each run's result/status) is extracted from logs and saved to an RDS Postgres instance with no expiry.
 
diff --git a/website/docs/dependency-pinning.md b/website/docs/dependency-pinning.md
index 08b6d1c039abcf62d45f7f90a14d68b8e6b4079c..320997dc669d78b6743629e668b37b85da0cdb2b 100644
--- a/website/docs/dependency-pinning.md
+++ b/website/docs/dependency-pinning.md
@@ -73,10 +73,10 @@ Another example of a good candidate for automerging might be a database driver l
 
 In the above suggestion of Pull Request automerging, you might still find it annoying if you receive GitHub Notifications for every PR that is created and merged. In that case, you could set `automergeType` to `branch-push`, which means Renovate will:
 
-* Create a new branch for testing
-* Wait until after tests have completed
-* Push the commit directly to `master` if tests pass, or
-* Raise a PR only if tests failed
+- Create a new branch for testing
+- Wait until after tests have completed
+- Push the commit directly to `master` if tests pass, or
+- Raise a PR only if tests failed
 
 With this approach, updates will be essentially "silent" - causing no notifications - but you will be able to see each commit on `master` of course.
 
@@ -86,8 +86,8 @@ Although it can feel satisfying to receive updates "immediately" when they're av
 
 So to reduce the interruptions of automated dependency updates, consider putting Renovate on a schedule, such as:
 
-* Update only on weekends? This way you update packages at most once per week, _and_ your CI build runners are likely to be idle anyway.
-* Update daily, but between hours like midnight and 5am? That way notifications don't pop up in people's feed while they're working, _and_ you also get the benefit of not tying up build machines when developers need to use them.
+- Update only on weekends? This way you update packages at most once per week, _and_ your CI build runners are likely to be idle anyway.
+- Update daily, but between hours like midnight and 5am? That way notifications don't pop up in people's feed while they're working, _and_ you also get the benefit of not tying up build machines when developers need to use them.
 
 ##### Grouping related packages
 
diff --git a/website/docs/docker.md b/website/docs/docker.md
index 73b898b30795446c24d5f5cee636009e6b27969e..2c20d87eb6ae6aa28b7e26b942023da125c1e652 100644
--- a/website/docs/docker.md
+++ b/website/docs/docker.md
@@ -42,8 +42,8 @@ Currently, Renovate will upgrade minor/patch versions (e.g. from `8.8` to `8.9`
 
 Renovate has a some docker-specific intelligence when it comes to versions. For example:
 
-* It understands that tag suffixes are frequently used, such as `node:8.9-onbuild`. Renovate will only upgrade from/to the same suffix.
-* It understands that some dependencies (e.g. `node` and `ubuntu`) use even numbers for stable and odd for unstable. Renovate won't upgrade from stable unstable
+- It understands that tag suffixes are frequently used, such as `node:8.9-onbuild`. Renovate will only upgrade from/to the same suffix.
+- It understands that some dependencies (e.g. `node` and `ubuntu`) use even numbers for stable and odd for unstable. Renovate won't upgrade from stable unstable
 
 ## Configuring/Disabling
 
diff --git a/website/docs/faq.md b/website/docs/faq.md
index e9e3eef6522d812a7adc607c9c7b1df1daa32556..0636d0eb6d0a97543f90ba3e69193638e55c4ef2 100644
--- a/website/docs/faq.md
+++ b/website/docs/faq.md
@@ -9,15 +9,15 @@ description: Frequently Asked Questions for Renovate Configuration
 
 Renovate will:
 
-* Look for configuration options in a configuration file (e.g. `renovate.json`) and in each
+- Look for configuration options in a configuration file (e.g. `renovate.json`) and in each
   `package.json` file
-* Find and process all package files (e.g. `package.json`, `package.js`, `Dockerfile`, etc) in each repository
-* Use separate branches/PR for each dependency
-* Use separate branches for each _major_ version of each dependency
-* Pin devDependencies to a single version, rather than use ranges
-* Pin dependencies to a single version if it appears not to be a library
-* Update `yarn.lock` and/or `package-lock.json` files if found
-* Create Pull Requests immediately after branch creation
+- Find and process all package files (e.g. `package.json`, `package.js`, `Dockerfile`, etc) in each repository
+- Use separate branches/PR for each dependency
+- Use separate branches for each _major_ version of each dependency
+- Pin devDependencies to a single version, rather than use ranges
+- Pin dependencies to a single version if it appears not to be a library
+- Update `yarn.lock` and/or `package-lock.json` files if found
+- Create Pull Requests immediately after branch creation
 
 ## What If I Need To .. ?
 
@@ -96,9 +96,9 @@ present. Multiple entries in the array means "or".
 
 You could:
 
-* Use `ignorePaths` to ignore certain paths in the repository, or
-* Explicitly list every package file you want renovated, in the `packageFiles` configuration object, or
-* Add a `renovate` section to any `package.json` files you don't want renovated,
+- Use `ignorePaths` to ignore certain paths in the repository, or
+- Explicitly list every package file you want renovated, in the `packageFiles` configuration object, or
+- Add a `renovate` section to any `package.json` files you don't want renovated,
   with the configuration option `"enabled": false`
 
 ### Disable renovate for certain dependency types
@@ -215,8 +215,8 @@ Of course, most people don't want _more_ PRs, so you would probably want to
 utilise this feature to make less work for yourself instead. As an example, you
 might:
 
-* Update patch updates daily and automerge if they pass tests
-* Update minor and major updates weekly
+- Update patch updates daily and automerge if they pass tests
+- Update minor and major updates weekly
 
 The result of this would hopefully be that you barely notice Renovate during the
 week while still getting the benefits of patch updates.
diff --git a/website/docs/node.md b/website/docs/node.md
index fe99a3562b0ee7e1eb9a6a9979bb5919194a3418..d01def0eaa3ddb5dd667be042b6173ecf3536c82 100644
--- a/website/docs/node.md
+++ b/website/docs/node.md
@@ -11,9 +11,9 @@ Renovate can upgrade the [Node.js](https://nodejs.org/en/) runtime used by your
 
 Renovate is capable of managing the Node.js version in the following files:
 
-* The [`engines`](https://docs.npmjs.com/files/package.json#engines) field in [`package.json`](https://docs.npmjs.com/files/package.json).
-* The [`.nvmrc`](https://github.com/creationix/nvm#nvmrc) file for the [Node Version Manager](https://github.com/creationix/nvm).
-* The [`node_js`](https://docs.travis-ci.com/user/languages/javascript-with-nodejs/#Specifying-Node.js-versions) field in [`.travis.yml`](https://docs.travis-ci.com/user/customizing-the-build/).
+- The [`engines`](https://docs.npmjs.com/files/package.json#engines) field in [`package.json`](https://docs.npmjs.com/files/package.json).
+- The [`.nvmrc`](https://github.com/creationix/nvm#nvmrc) file for the [Node Version Manager](https://github.com/creationix/nvm).
+- The [`node_js`](https://docs.travis-ci.com/user/languages/javascript-with-nodejs/#Specifying-Node.js-versions) field in [`.travis.yml`](https://docs.travis-ci.com/user/customizing-the-build/).
 
 ## How It Works
 
diff --git a/website/docs/noise-reduction.md b/website/docs/noise-reduction.md
index f790f2819a944afb14d39ff3df042975177ccb8f..463882390f1e6a692f85ec97f49c79a26dcc1e64 100644
--- a/website/docs/noise-reduction.md
+++ b/website/docs/noise-reduction.md
@@ -88,9 +88,9 @@ For example, if you have `jest` or `mocha` as a dependency, and it has an upgrad
 
 Those of you familiar with GitHub might note that even if you automerge PRs, you are still going to get notifications (noise) anyway - one when the PR is created and another when it is merged. For this reason we recommend you consider setting `automergeType=branch-push` which will mean:
 
-* Renovate first creates a branch and no PR
-* If tests pass, Renovate pushes a commit directly to `master` without PR
-* If tests fail, Renovate raises a PR for you to review
+- Renovate first creates a branch and no PR
+- If tests pass, Renovate pushes a commit directly to `master` without PR
+- If tests fail, Renovate raises a PR for you to review
 
 The result is that passing updates are essentially "silent" - the only sign of them are the commits to your `master` branch.
 
@@ -98,12 +98,12 @@ The result is that passing updates are essentially "silent" - the only sign of t
 
 Automerging is particularly beneficial if you have configured a schedule, because Renovate on its own may be able to automerge the majority of your updates. And this is especially so if your repository needs rebasing, e.g. because you use lock files. e.g. let's say you have dependencies `abc` and `xyz` with upgrades, and you use a `yarn.lock` file.
 
-* At start of schedule, `Renovate` will create branches for `abc` and `xyz` upgrades, including `yarn.lock` updates
-* After `abc` passes tests, `Renovate` will automerge it to `master`
-* The `xyz` branch probably now has `yarn.lock` conflicts
-* Renovate will immediately check all other branches and rebase them
-* The change to `xyz` branch will trigger another round of CI tests
-* After the updated `xyz` branch passes, Renovate will automerge it too
+- At start of schedule, `Renovate` will create branches for `abc` and `xyz` upgrades, including `yarn.lock` updates
+- After `abc` passes tests, `Renovate` will automerge it to `master`
+- The `xyz` branch probably now has `yarn.lock` conflicts
+- Renovate will immediately check all other branches and rebase them
+- The change to `xyz` branch will trigger another round of CI tests
+- After the updated `xyz` branch passes, Renovate will automerge it too
 
 This is a lot better than you waking up to two PRs and then having to deal with conflicts yourself after you merge the first one.
 
@@ -127,9 +127,9 @@ Have you come up with a rule that you think others would benefit from? How about
 
 As mentioned earlier. using lock files greatly increase the chance that merging one PR will result in a second PR becoming conflicted with `master`. Therefore:
 
-* The more groups you use, the separate PRs you have, and hence the less overall chance at lock file conflicts
-* The less your schedule, the more chance that you pile up concurrent PRs, which increases the chance of lock file conflicts
-* The more automerging you do, the less chance you have concurrent PRs, which decreases the chance of lock file conflicts
+- The more groups you use, the separate PRs you have, and hence the less overall chance at lock file conflicts
+- The less your schedule, the more chance that you pile up concurrent PRs, which increases the chance of lock file conflicts
+- The more automerging you do, the less chance you have concurrent PRs, which decreases the chance of lock file conflicts
 
 ## The Future of Noise Reduction
 
diff --git a/website/docs/semantic-commits.md b/website/docs/semantic-commits.md
index d0e23cff41dd5b0845c18aba961b0613df24a821..52e5706525a0d8a5c49299bc07ca8e208d4c2eef 100644
--- a/website/docs/semantic-commits.md
+++ b/website/docs/semantic-commits.md
@@ -11,8 +11,8 @@ Currently, Renovate ignores commit conventions apart from "angular".
 
 If angular-style commits are found then Renovate will structure its commit messages and PR titles to be like so:
 
-* chore(deps): update eslint to v4.2.0
-* fix(deps): update express to v4.16.2
+- chore(deps): update eslint to v4.2.0
+- fix(deps): update express to v4.16.2
 
 `chore` is used by default, but `fix` is used for anything in the "dependencies" section of `package.json`.
 
diff --git a/website/docs/updating-rebasing.md b/website/docs/updating-rebasing.md
index 838cb830d0a9706a6cc43d3fbe4a014a11c52ee5..f3b6eccb49e414c8ad0551f26f0be8f750347284 100644
--- a/website/docs/updating-rebasing.md
+++ b/website/docs/updating-rebasing.md
@@ -30,5 +30,5 @@ In that case Renovate PRs will be continuously rebased off the repository's base
 
 If an existing PR is open to upgrade dependency "foo" to v1.1.0 and then v1.1.1 is released, then Renovate will regenerate the branch again. This way:
 
-* Each Renovate branch will always have 1 and only 1 commit
-* The newest version will be based off the latest base branch commit at the time
+- Each Renovate branch will always have 1 and only 1 commit
+- The newest version will be based off the latest base branch commit at the time
diff --git a/yarn.lock b/yarn.lock
index 79edeb911ec0b54d188d73180cf6d592dffb2c96..a939d7557b59f3b61dd4bdef5043c77c35432057 100644
--- a/yarn.lock
+++ b/yarn.lock
@@ -5319,9 +5319,9 @@ preserve@^0.2.0:
   version "0.2.0"
   resolved "https://registry.yarnpkg.com/preserve/-/preserve-0.2.0.tgz#815ed1f6ebc65926f865b310c0713bcb3315ce4b"
 
-prettier@1.12.1:
-  version "1.12.1"
-  resolved "https://registry.yarnpkg.com/prettier/-/prettier-1.12.1.tgz#c1ad20e803e7749faf905a409d2367e06bbe7325"
+prettier@1.13.0:
+  version "1.13.0"
+  resolved "https://registry.yarnpkg.com/prettier/-/prettier-1.13.0.tgz#054de8d5fb1a4405c845d16183f58a2c301f6f16"
 
 pretty-format@^23.0.1:
   version "23.0.1"