From 4101fa40a6889d26c67ddfd5a049f78bbbb51762 Mon Sep 17 00:00:00 2001
From: Rhys Arkins <rhys@arkins.net>
Date: Sat, 2 Dec 2017 20:29:55 +0100
Subject: [PATCH] chore: enable prettier on markdown files

---
 contributing.md           |  32 ++++---
 docs/configuration.md     |  49 ++++++-----
 docs/deployment.md        |  27 ++++--
 docs/design-decisions.md  | 108 ++++++++++++++++--------
 docs/faq.md               | 171 ++++++++++++++++++++++++++------------
 docs/shareable-configs.md |  60 ++++++++-----
 docs/status-checks.md     |  15 +++-
 package.json              |   2 +-
 readme.md                 |  70 +++++++++++-----
 9 files changed, 364 insertions(+), 170 deletions(-)

diff --git a/contributing.md b/contributing.md
index 344e8b6439..cbaca3bd7e 100644
--- a/contributing.md
+++ b/contributing.md
@@ -2,18 +2,22 @@
 
 Contributions are welcome and desirable, in the form of:
 
-- Bug reports (raise an issue)
-- Feature requests (raise an issue)
-- Code (submit a Pull Request)
-- Comments (comment on any of the above)
+* Bug reports (raise an issue)
+* Feature requests (raise an issue)
+* Code (submit a Pull Request)
+* Comments (comment on any of the above)
 
-Before you start any Pull Request, it's recommended that you raise an issue first if you have any doubts. That way you can be sure that the maintainer(s) agree on what to change and how, and you can hopefully get a quick merge afterwards.
+Before you start any Pull Request, it's recommended that you raise an issue
+first if you have any doubts. That way you can be sure that the maintainer(s)
+agree on what to change and how, and you can hopefully get a quick merge
+afterwards.
 
 ## Running the source code locally
 
 After you have cloned the project, first check that it's running OK locally.
 
-First you will need to install dependencies. We use [yarn](https://github.com/yarnpkg/yarn) so run `yarn` instead of `npm install`.
+First you will need to install dependencies. We use
+[yarn](https://github.com/yarnpkg/yarn) so run `yarn` instead of `npm install`.
 
 `renovate` supports nodejs versions 8 and above.
 
@@ -27,13 +31,19 @@ $ yarn start -- --labels=foo username/reponame
 
 ## Adding configuration options
 
-We wish to keep backwards-compatibility as often as possible, as well as make the code configurable, so most new functionality should be controllable via configuration options.
-Please see [Configuration docs](docs/configuration.md) for a list of current options.
+We wish to keep backwards-compatibility as often as possible, as well as make
+the code configurable, so most new functionality should be controllable via
+configuration options. Please see [Configuration docs](docs/configuration.md)
+for a list of current options.
 
-If you wish to add one, add it to `lib/config/definitions.js` and then run `yarn run update-docs`.
+If you wish to add one, add it to `lib/config/definitions.js` and then run `yarn
+run update-docs`.
 
 ## Running tests
 
-You can run `yarn test` locally to test your code. We also run Continuous Integration using CircleCI.
+You can run `yarn test` locally to test your code. We also run Continuous
+Integration using CircleCI.
 
-We use [Prettier](https://github.com/prettier/prettier) for code formatting. If your code fails `yarn test` due to a `prettier` rule in `eslint` then it can be fixed by running `yarn run lint-fix`;
+We use [Prettier](https://github.com/prettier/prettier) for code formatting. If
+your code fails `yarn test` due to a `prettier` rule in `eslint` then it can be
+fixed by running `yarn run lint-fix`;
diff --git a/docs/configuration.md b/docs/configuration.md
index db30434596..f39950b92b 100644
--- a/docs/configuration.md
+++ b/docs/configuration.md
@@ -3,24 +3,32 @@
 ## Configuration Methods
 
 Configuration is supported via any or all of the below:
-- Configuration file
-- Environment
-- CLI
-- `renovate.json` 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 overrides the config file, which overrides defaults.
+* Configuration file
+* Environment
+* CLI
+* `renovate.json` 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
+overrides the config file, which overrides defaults.
 
 ### Default Configuration
 
-Default configuration values can be found in [lib/config/definitions.js](../lib/config/definitions.js)
+Default configuration values can be found in
+[lib/config/definitions.js](../lib/config/definitions.js)
 
 ### Configuration File
 
-You can override default configuration using a configuration file, with default name `config.js` in the working directory. If you need an alternate location or name, set it in the environment variable `RENOVATE_CONFIG_FILE`.
+You can override default configuration using a configuration file, with default
+name `config.js` in the working directory. If you need an alternate location or
+name, set it in the environment variable `RENOVATE_CONFIG_FILE`.
 
-Using a configuration file gives you very granular configuration options. For instance, you can override most settings at the global (file), repository, or package level. e.g. apply one set of labels for `backend/package.json` and a different set for `frontend/package.json` in the same repository.
+Using a configuration file gives you very granular configuration options. For
+instance, you can override most settings at the global (file), repository, or
+package level. e.g. apply one set of labels for `backend/package.json` and a
+different set for `frontend/package.json` in the same repository.
 
 ```javascript
 module.exports = {
@@ -33,7 +41,7 @@ module.exports = {
         'package.json',
         {
           packageFile: 'frontend/package.json',
-          labels: ['upgrade', 'frontend']
+          labels: ['upgrade', 'frontend'],
         },
       ],
     },
@@ -57,7 +65,7 @@ module.exports = {
       labels: ['jquery', 'uhoh'],
     },
   ],
-}
+};
 ```
 
 ### CLI
@@ -66,17 +74,21 @@ module.exports = {
 $ node renovate --help
 ```
 
-To configure any `<list>` items, separate with commas. E.g. `renovate --labels=renovate,dependency`.
+To configure any `<list>` items, separate with commas. E.g. `renovate
+--labels=renovate,dependency`.
 
 ### renovate.json
 
-If you add a `renovate.json` file to the root of your repository, you can use this to override default settings.
-If you leave the `packageFiles` field empty then `renovate` will still auto-discover all `package.json` files in the repository.
+If you add a `renovate.json` file to the root of your repository, you can use
+this to override default settings. If you leave the `packageFiles` field empty
+then `renovate` will still auto-discover all `package.json` files in the
+repository.
 
 ### package.json
 
-If you add configuration options to your `package.json` then these will override any other settings above.
-Obviously, you can't set repository or package file location with this method.
+If you add configuration options to your `package.json` then these will override
+any other settings above. Obviously, you can't set repository or package file
+location with this method.
 
 ```json
 "renovate": {
@@ -509,7 +521,6 @@ Obviously, you can't set repository or package file location with this method.
   "recreateClosed": true,
   "rebaseStalePrs": true,
   "groupName": "Pin Dependencies",
-  "semanticCommitType": "refactor",
   "group": {"commitMessage": "Pin Dependencies", "prTitle": "{{groupName}}"}
 }</pre></td>
   <td>`RENOVATE_PIN`</td>
@@ -519,7 +530,7 @@ Obviously, you can't set repository or package file location with this method.
   <td>`digest`</td>
   <td>Configuration to apply when updating a Docker digest (same tag)</td>
   <td>json</td>
-  <td><pre>{"semanticCommitType": "refactor"}</pre></td>
+  <td><pre>{}</pre></td>
   <td>`RENOVATE_DIGEST`</td>
   <td><td>
 </tr>
diff --git a/docs/deployment.md b/docs/deployment.md
index 2161acd673..068feb5011 100644
--- a/docs/deployment.md
+++ b/docs/deployment.md
@@ -1,6 +1,7 @@
 # Deployment
 
-Before deploying the script for scheduled runs, it's recommend you test your settings locally first.
+Before deploying the script for scheduled runs, it's recommend you test your
+settings locally first.
 
 ## Server cron
 
@@ -12,15 +13,16 @@ Install using `npm install -g`.
 
 ### Configuration
 
-At a minimum, you will need to configure the token and repository list.
-Simplest would be to specify both via CLI.
-Alternatively, configure the token via Environment Variable if you don't want it to show in any cron logs.
+At a minimum, you will need to configure the token and repository list. Simplest
+would be to specify both via CLI. Alternatively, configure the token via
+Environment Variable if you don't want it to show in any cron logs.
 
 Running daily should suit most people. At most, hourly.
 
 ## Heroku
 
-Heroku free dynos provide a good way to host this for free. Set it up with the following commands:
+Heroku free dynos provide a good way to host this for free. Set it up with the
+following commands:
 
 ### Installation
 
@@ -40,9 +42,11 @@ You now need to set the token.
 ```
 $ heroku config:set GITHUB_TOKEN=[YourGitHubToken]
 ```
+
 (or use `GITLAB_TOKEN` if appropriate)
 
-You should also set any other [Configuration Options](configuration.md) you need.
+You should also set any other [Configuration Options](configuration.md) you
+need.
 
 The app should now be ready for testing.
 
@@ -50,12 +54,17 @@ The app should now be ready for testing.
 $ heroku run renovate [your/repo]
 ```
 
-Once you've verified the script ran successfully, it's time to set it up for automatic scheduling.
+Once you've verified the script ran successfully, it's time to set it up for
+automatic scheduling.
+
 ```
 $ heroku addons:create scheduler:standard
 $ heroku addons:open scheduler
 ```
 
-At this point you should have the Heroku Scheduler Dashboard open. Click "Add new job" and enter the same command as you ran previously (e.g. `renovate [your/repo]`). Adjust the frequency to hourly if you prefer, then click Save.
+At this point you should have the Heroku Scheduler Dashboard open. Click "Add
+new job" and enter the same command as you ran previously (e.g. `renovate
+[your/repo]`). Adjust the frequency to hourly if you prefer, then click Save.
 
-You can run `heroku logs` to check execution logs. Consider adjusting the scripts log level if you have problems (info -> verbose -> debug -> silly).
+You can run `heroku logs` to check execution logs. Consider adjusting the
+scripts log level if you have problems (info -> verbose -> debug -> silly).
diff --git a/docs/design-decisions.md b/docs/design-decisions.md
index 9eb1285606..b2fd413fce 100644
--- a/docs/design-decisions.md
+++ b/docs/design-decisions.md
@@ -4,44 +4,55 @@ This file documents the design choices as well as configuration options.
 
 #### Stateless
 
-No state storage is needed on `renovate` or the source code repository apart from what you see publicly (branches, Pull Requests). It therefore doesn't matter if you stop/restart the script and would even still work if you had it running from two different locations, as long as their configuration was the same.
+No state storage is needed on `renovate` or the source code repository apart
+from what you see publicly (branches, Pull Requests). It therefore doesn't
+matter if you stop/restart the script and would even still work if you had it
+running from two different locations, as long as their configuration was the
+same.
 
 #### API only
 
-So far, nothing we need to do requires a full `git clone` of the repository. e.g. we do not need to perform a git clone of the entire repository. Therefore, all operations are performed via the API.
+So far, nothing we need to do requires a full `git clone` of the repository.
+e.g. we do not need to perform a git clone of the entire repository. Therefore,
+all operations are performed via the API.
 
 ## Synchronous Operation
 
-The script current processes repositories, package files, and dependencies within them all synchronously.
+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.
 
 ## Multiple Configuration Methods
 
-The script supports multiple [configuration methods](configuration.md) concurrently, and processed in order of priority.
-This allows examples such as token configured via environment variable and labels configured via target `package.json`.
+The script supports multiple [configuration methods](configuration.md)
+concurrently, and processed in order of priority. This allows examples such as
+token configured via environment variable and labels configured via target
+`package.json`.
 
 ## Cascading Configuration
 
-Configuration options applied per-package override those applied per package-type, which override those per-repository, which override those which are global (all repositories).
+Configuration options applied per-package override those applied per
+package-type, which override those per-repository, which override those which
+are global (all repositories).
 
 The following options can be configured down to a per-package type level:
 
-- Dependency Types
-- Ignored Dependencies
+* Dependency Types
+* Ignored Dependencies
 
 The following options apply per-repository:
 
-- Token
-- Platform
-- Endpoint
+* Token
+* Platform
+* Endpoint
 
 The following options apply globally:
 
-- Log Level
+* Log Level
 
 The remaining configuration options can be applied per-package.
 
@@ -49,59 +60,88 @@ The remaining configuration options can be applied per-package.
 
 Note: GitHub only.
 
-Default behaviour is to auto-discover all `package.json` locations in a repository and process them all.
-Doing so means that "monorepos" are supported by default.
-This can be overridden by the configuration option `packageFiles`, where you list the file paths manually (e.g. limit to just `package.json` in root of repository).
+Default behaviour is to auto-discover all `package.json` locations in a
+repository and process them all. Doing so means that "monorepos" are supported
+by default. This can be overridden by the configuration option `packageFiles`,
+where you list the file paths manually (e.g. limit to just `package.json` in
+root of repository).
 
 ## Separate Branches per dependency
 
-By default, `renovate` will maintain separate branches per-dependency. So if 20 dependencies need updating, there will be at least 20 branches/PRs. Although this may seem undesirable, it was considered even less desirable if all 20 were in the same Pull Request and it's up to the users to determine which dependency upgrade(s) caused the build to fail.
+By default, `renovate` will maintain separate branches per-dependency. So if 20
+dependencies need updating, there will be at least 20 branches/PRs. Although
+this may seem undesirable, it was considered even less desirable if all 20 were
+in the same Pull Request and it's up to the users to determine which dependency
+upgrade(s) caused the build to fail.
 
-However, it's still possible to override the default branch and PR name templates in such a way to produce a single branch for all dependencies. The `groupName` configuration option can be used at a repository level (e.g. give it the value `All`) and then all dependency updates will be in the same branch/PR.
+However, it's still possible to override the default branch and PR name
+templates in such a way to produce a single branch for all dependencies. The
+`groupName` configuration option can be used at a repository level (e.g. give it
+the value `All`) and then all dependency updates will be in the same branch/PR.
 
 ## One PR per Major release
 
-`renovate` will create multiple branches/PRs if multiple major branch upgrades 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).
+`renovate` will create multiple branches/PRs if multiple major branch upgrades
+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 immediately.
-- 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 even if a new Major release exists
+* 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
+  or Patch updates.
+* Projects should get Minor and Patch updates for their current Major release
+  even if a new Major release exists
 
 This can be overriden via the config option `separateMajorReleases`.
 
 ## Branch naming
 
-Branches are named like `renovate/webpack-1.x` instead of `renovate/webpack-1.2.0`.
+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` release happens
+* 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.
 
 ## Pull Request Recreation
 
-By default, the script does not create a new PR if it finds an identical one already closed. This allows users to close unwelcome upgrade PRs and worry about them being recreated every run. Typically this is most useful for major upgrades.
-This option is configurable.
+By default, the script does not create a new PR if it finds an identical one
+already closed. This allows users to close unwelcome upgrade PRs and worry about
+them being recreated every run. Typically this is most useful for major
+upgrades. This option is configurable.
 
 ## Range handling
 
-`renovate` prefers pinned dependency versions, instead of maintaining ranges. Even if the project is using tilde ranges, why not pin them for consistency if you're also using `renovate` every day?
+`renovate` prefers pinned dependency versions, instead of maintaining ranges.
+Even if the project is using tilde ranges, why not pin them for consistency if
+you're also using `renovate` every day?
 
 This is now configurable via the `pinVersions` configuration option.
 
 ## Rebasing Unmergeable Pull Requests
 
-Note: GitHub only. GitLab does not expose enough low level git API to allow this.
+Note: GitHub only. GitLab does not expose enough low level git API to allow
+this.
 
-With the default behaviour of one branch per dependency, it's often that case that a PR gets merge conflicts after an adjacent dependency update is merged. Although GitHub has added a web interface for simple merge conflicts, this is still annoying to resolve manually.
+With the default behaviour of one branch per dependency, it's often that case
+that a PR gets merge conflicts after an adjacent dependency update is merged.
+Although GitHub has added a web interface for simple merge conflicts, this is
+still annoying to resolve manually.
 
-`renovate` will rebase any unmergeable branches and add the latest necessary commit on top of the most recent `master` commit.
+`renovate` will rebase any unmergeable branches and add the latest necessary
+commit on top of the most recent `master` commit.
 
-Note: `renovate` will only do this if the original branch hasn't been modified by anyone else.
+Note: `renovate` will only do this if the original branch hasn't been modified
+by anyone else.
 
 ## Suppressing string templates from CLI
 
-String templates (e.g. commit or PR name) are not configurable via CLI options, in order to not pollute the CLI help and make it unreadable. If you must configure via CLI, use an environment variable instead. e.g.
+String templates (e.g. commit or PR name) are not configurable via CLI options,
+in order to not pollute the CLI help and make it unreadable. If you must
+configure via CLI, use an environment variable instead. e.g.
 
 ```sh
 $ RENOVATE_BRANCH_NAME=foo renovate
diff --git a/docs/faq.md b/docs/faq.md
index 6c785811ca..44534d3e4f 100644
--- a/docs/faq.md
+++ b/docs/faq.md
@@ -1,29 +1,39 @@
 # FAQ
 
-If you need a specific behaviour and it's not mentioned here - or it's more complicated - feel free to raise an [Issue](https://github.com/renovateapp/renovate/issues) - configuration questions are welcome in this repository.
+If you need a specific behaviour and it's not mentioned here - or it's more
+complicated - feel free to raise an
+[Issue](https://github.com/renovateapp/renovate/issues) - configuration
+questions are welcome in this repository.
 
 ## What Is The Default Behaviour?
 
 Renovate will:
 
--   Look for configuration options in a `renovate.json` file and in each `package.json` file under the `renovate` object
--   Find and process all `package.json` files in each repository
--   Process `dependencies`, `devDependencies` and `optionalDependencies` in each `package.json`
--   Use separate branches/PR for each dependency
--   Use separate branches for each *major* version of each dependency
--   Pin dependencies to a single version, rather than use ranges
--   Update `yarn.lock` and/or `package-lock.json` files if found
--   Create Pull Requests immediately after branch creation
+* Look for configuration options in a `renovate.json` file and in each
+  `package.json` file under the `renovate` object
+* Find and process all `package.json` files in each repository
+* Process `dependencies`, `devDependencies` and `optionalDependencies` in each
+  `package.json`
+* Use separate branches/PR for each dependency
+* Use separate branches for each _major_ version of each dependency
+* Pin dependencies to a single version, rather than use ranges
+* Update `yarn.lock` and/or `package-lock.json` files if found
+* Create Pull Requests immediately after branch creation
 
 ## What If I Need To .. ?
 
 ### Run renovate on all repositories that the account has access to
 
-Set configuration option `autodiscover` to `true`, via CLI, environment, or configuration file. Obviously it's too late to set it in any `renovate.json` or `package.json`.
+Set configuration option `autodiscover` to `true`, via CLI, environment, or
+configuration file. Obviously it's too late to set it in any `renovate.json` or
+`package.json`.
 
 ### Use an alternative branch for Pull Request target
 
-If for example your repository default branch is `master` but your Pull Requests should target branch `next`, then you can configure this via the `baseBranch` configuration option. To do this, add this line to the `renovate.json` in the *default* branch (i.e. `master` in this example).
+If for example your repository default branch is `master` but your Pull Requests
+should target branch `next`, then you can configure this via the `baseBranch`
+configuration option. To do this, add this line to the `renovate.json` in the
+_default_ branch (i.e. `master` in this example).
 
 ```
 {
@@ -33,30 +43,47 @@ If for example your repository default branch is `master` but your Pull Requests
 
 ### Support private npm modules
 
-If you are running your own Renovate instance, then the easiest way to support private modules is to make sure the appropriate credentials are in `.npmrc` or `~/.npmrc`;
+If you are running your own Renovate instance, then the easiest way to support
+private modules is to make sure the appropriate credentials are in `.npmrc` or
+`~/.npmrc`;
 
-If you are using a hosted Renovate instance (such as the Renovate app), and your `package.json` includes private modules, then you can:
+If you are using a hosted Renovate instance (such as the Renovate app), and your
+`package.json` includes private modules, then you can:
 
-1.  Commit an `.npmrc` file to the repository, and Renovate will use this, or
-2.  Add the contents of your `.npmrc` file to the config field `npmrc` in your `renovate.json` or `package.json` renovate config
-3. Add a valid npm authToken to the config field `npmToken` in your `renovate.json` or `package.json` renovate config
-4.  If using the [GitHub App hosted service](https://github.com/apps/renovate), authorize the npm user named "renovate" with read-only access to the relevant modules. This "renovate" account is used solely for the purpose of the renovate GitHub App.
+1. Commit an `.npmrc` file to the repository, and Renovate will use this, or
+2. Add the contents of your `.npmrc` file to the config field `npmrc` in your
+   `renovate.json` or `package.json` renovate config
+3. Add a valid npm authToken to the config field `npmToken` in your
+   `renovate.json` or `package.json` renovate config
+4. If using the [GitHub App hosted service](https://github.com/apps/renovate),
+   authorize the npm user named "renovate" with read-only access to the relevant
+   modules. This "renovate" account is used solely for the purpose of the
+   renovate GitHub App.
 
 ### Control renovate's schedule
 
-Renovate itself will run as often as its administrator has configured it (e.g. hourly, daily, etc). But you may wish to update certain repositories less often, or even specific packages at a different schedule.
+Renovate itself will run as often as its administrator has configured it (e.g.
+hourly, daily, etc). But you may wish to update certain repositories less often,
+or even specific packages at a different schedule.
 
-If you want to control the days of the week or times of day that renovate updates packages, use the `timezone` and `schedule` configuration options.
+If you want to control the days of the week or times of day that renovate
+updates packages, use the `timezone` and `schedule` configuration options.
 
-By default, Renovate schedules will use the timezone of the machine that it's running on. This can be overridden in global config. Finally, it can be overridden on a per-repository basis too, e.g.:
+By default, Renovate schedules will use the timezone of the machine that it's
+running on. This can be overridden in global config. Finally, it can be
+overridden on a per-repository basis too, e.g.:
 
 ```
   "timezone": "America/Los_Angeles",
 ```
 
-The timezone must be one of the valid [IANA time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).
+The timezone must be one of the valid
+[IANA time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).
 
-Now that your timezone is set, you can define days of week or hours of the day in which renovate will make changes. For this we rely on text parsing of the library [later](http://bunkat.github.io/later/parsers.html#text) and its concepts of "days", "time_before", and "time_after".
+Now that your timezone is set, you can define days of week or hours of the day
+in which renovate will make changes. For this we rely on text parsing of the
+library [later](http://bunkat.github.io/later/parsers.html#text) and its
+concepts of "days", "time_before", and "time_after".
 
 Example scheduling:
 
@@ -68,7 +95,8 @@ before 5:00am
 on friday and saturday
 ```
 
-This scheduling feature can be particularly useful for "noisy" packages that are updated frequently, such as `aws-sdk`.
+This scheduling feature can be particularly useful for "noisy" packages that are
+updated frequently, such as `aws-sdk`.
 
 To restrict `aws-sdk` to only weekly updates, you could add this package rule:
 
@@ -81,22 +109,29 @@ To restrict `aws-sdk` to only weekly updates, you could add this package rule:
   ]
 ```
 
-Note that schedule must be in the form of an array, even if only one schedule is present. Multiple entries in the array means "or".
+Note that schedule must be in the form of an array, even if only one schedule is
+present. Multiple entries in the array means "or".
 
 ### Selectively enable or disable renovate for specific `package.json` files
 
 You could:
 
--   Add a `renovate.json` to the root of your repository and explicitly whitelist which `package.json` files you want renovated in the `packageFiles` configuration option, or
--   Add a `renovate` section to any `package.json` files you don't want renovated, with the configuration option `"enabled": false`
+* Add a `renovate.json` to the root of your repository and explicitly whitelist
+  which `package.json` files you want renovated in the `packageFiles`
+  configuration option, 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
 
-If you want to disable `renovate` for `optionalDependencies`, for example, you could define your own `depTypes` array (in either a `renovate.json` or `package.json` file)
+If you want to disable `renovate` for `optionalDependencies`, for example, you
+could define your own `depTypes` array (in either a `renovate.json` or
+`package.json` file)
 
 ### Use a single branch/PR for all dependency upgrades
 
-Add a configuration for configuration option `groupName` set to value `"all"`, at the top level of your `renovate.json` or `package.json`.
+Add a configuration for configuration option `groupName` set to value `"all"`,
+at the top level of your `renovate.json` or `package.json`.
 
 ### Use separate branches per dependency, but not one per major release
 
@@ -108,7 +143,9 @@ Set configuration option `pinVersions` to `false`.
 
 ### Keep lock files (including sub-dependencies) up-to-date, even when `package.json` hasn't changed
 
-This is enabled by default, but its schedule is set to `['before 5am on monday']`. If you want it more frequently, then update the `schedule` field inside the `lockFileMaintenance` object.
+This is enabled by default, but its schedule is set to `['before 5am on
+monday']`. If you want it more frequently, then update the `schedule` field
+inside the `lockFileMaintenance` object.
 
 ### Wait until tests have passed before creating the PR
 
@@ -128,10 +165,10 @@ Set the configuration option `labels` to an array of labels to use
 
 ### Apply a rule, but only to package `abc`?
 
-1.  Add a `packageRules` array to your configuration.
-2.  Create one object inside this array
-3.  Set field `packageNames` to value `["abc"]`
-4.  Add the configuration option to the same object.
+1. Add a `packageRules` array to your configuration.
+2. Create one object inside this array
+3. Set field `packageNames` to value `["abc"]`
+4. Add the configuration option to the same object.
 
 e.g.
 
@@ -146,7 +183,8 @@ e.g.
 
 ### Apply a rule, but only for packages starting with `abc`
 
-Do the same as above, but instead of using `packageNames`, use `packagePatterns` and a regex. e.g.
+Do the same as above, but instead of using `packageNames`, use `packagePatterns`
+and a regex. e.g.
 
 ```
 "packageRules": [
@@ -172,7 +210,8 @@ As above, but apply a `groupName`, e.g.
 
 ### Change the default branch name, commit message, PR title or PR description
 
-Set the `branchName`, `commitMessage`, `prTitle` or `prBody` configuration options:
+Set the `branchName`, `commitMessage`, `prTitle` or `prBody` configuration
+options:
 
 ```
 "branchName": "vroom/{{depName}}-{{newVersionMajor}}.x",
@@ -182,25 +221,41 @@ Set the `branchName`, `commitMessage`, `prTitle` or `prBody` configuration optio
 
 ### Automatically merge passing Pull Requests
 
-Set configuration option `autoMerge` to `minor` if you want this to apply only to minor upgrades, or set to value `all` if you want it applied to both minor and major upgrades.
+Set configuration option `autoMerge` to `minor` if you want this to apply only
+to minor upgrades, or set to value `all` if you want it applied to both minor
+and major upgrades.
 
 ### Separate patch releases from minor releases
 
-Renovate's default behaviour is to separate major and minor releases, while patch releases are also consider "minor". For example if you were running `q@0.8.7` you would receive one branch for the minor update to `q@0.9.7` and a second for the major update to `q@1.4.1`.
+Renovate's default behaviour is to separate major and minor releases, while
+patch releases are also consider "minor". For example if you were running
+`q@0.8.7` you would receive one branch for the minor update to `q@0.9.7` and a
+second for the major update to `q@1.4.1`.
 
-If you set the configuration option `separatePatchReleases` to `true`, or you configure `automerge` to have value `"patch"`, then Renovate will then separate patch releases as well. For example, if you did this when running `q@0.8.7` then you'd receive three PRs - for `q@0.8.13`, `q@0.9.7` and `q@1.4.1`.
+If you set the configuration option `separatePatchReleases` to `true`, or you
+configure `automerge` to have value `"patch"`, then Renovate will then separate
+patch releases as well. For example, if you did this when running `q@0.8.7` then
+you'd receive three PRs - for `q@0.8.13`, `q@0.9.7` and `q@1.4.1`.
 
-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
+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:
 
-The result of this would hopefully be that you barely notice Renovate during the week while still getting the benefits of patch updates.
+* 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.
 
 ### Update Meteor package.js files
 
-Renovate supports Meteor's `package.js` files - specifically, the `Npm.depends` section. As with npm, it will not renovate any `http*` URLs, but will keep all semantic versions up to date. (e.g. update version `1.1.0` to `1.1.1`)
+Renovate supports Meteor's `package.js` files - specifically, the `Npm.depends`
+section. As with npm, it will not renovate any `http*` URLs, but will keep all
+semantic versions up to date. (e.g. update version `1.1.0` to `1.1.1`)
 
-Meteor support is opt-in, meaning Renvoate won't attempt to search for Meteor files by default. To enable it, add `":meteor"` to your Renovate config `extends` array.
+Meteor support is opt-in, meaning Renvoate won't attempt to search for Meteor
+files by default. To enable it, add `":meteor"` to your Renovate config
+`extends` array.
 
 e.g. if your renovate.json looks like:
 
@@ -220,17 +275,22 @@ Then update it to be:
 
 Once you've done this, Renovate will:
 
-- Search the repository for all `package.js` files which include `Npm.depends`
-- Check the npm registry for newer versinos for each detected dependency
-- Patch the `package.js` file if updates are found and create an associated branch/PR
+* Search the repository for all `package.js` files which include `Npm.depends`
+* Check the npm registry for newer versinos for each detected dependency
+* Patch the `package.js` file if updates are found and create an associated
+  branch/PR
 
-If you wish to combine upgrades into one PR or any other similar configuration, you can do this just like with `package.json` dependencies by adding configuration or presets to your `renovate.json` file.
+If you wish to combine upgrades into one PR or any other similar configuration,
+you can do this just like with `package.json` dependencies by adding
+configuration or presets to your `renovate.json` file.
 
 ### Update Dockerfile FROM dependencies
 
 Renovate supports updating `FROM` instructions in `Dockerfile`s.
 
-Dockerfile support is opt-in, meaning Renvoate won't attempt to search for Dockerfiles by default. To enable it, add `":docker"` to your Renovate config `extends` array.
+Dockerfile support is opt-in, meaning Renvoate won't attempt to search for
+Dockerfiles by default. To enable it, add `":docker"` to your Renovate config
+`extends` array.
 
 e.g. if your renovate.json looks like:
 
@@ -250,8 +310,13 @@ Then update it to be:
 
 Once you've done this, Renovate will:
 
-- Search the repository for all `Dockerfile` files that have `FROM x` as the first non-comment line
-- If x includes a digest, Renovate will check the Docker registry to see if a newer digest is available for the same tag and patch the Dockerfile
-- If x does not include a digest, Renovate will look up the current digest for this image/tag and add it to the Dockerfile
+* Search the repository for all `Dockerfile` files that have `FROM x` as the
+  first non-comment line
+* If x includes a digest, Renovate will check the Docker registry to see if a
+  newer digest is available for the same tag and patch the Dockerfile
+* If x does not include a digest, Renovate will look up the current digest for
+  this image/tag and add it to the Dockerfile
 
-If you wish to combine upgrades into one PR or any other similar configuration, you can do this just like with `package.json` dependencies by adding configuration or presets to your `renovate.json` file.
+If you wish to combine upgrades into one PR or any other similar configuration,
+you can do this just like with `package.json` dependencies by adding
+configuration or presets to your `renovate.json` file.
diff --git a/docs/shareable-configs.md b/docs/shareable-configs.md
index 86bae5dcb6..ba3552fea5 100644
--- a/docs/shareable-configs.md
+++ b/docs/shareable-configs.md
@@ -1,19 +1,30 @@
 # Preset configs
 
-Renovate uses the term "presets" to refer to shareable config snippets, similar to eslint. Unlike eslint though:
+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 config
--   Shared config files can contain many presets
+* 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
 
 ## Preset config URIs
 
 In human-understandable form, the rules are:
 
--   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 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 `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, 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. e.g. `:webapp` (not the leading `:`) expands to `renovate-config-default:webapp`
+* 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
+  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
+  `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,
+  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.
+  e.g. `:webapp` (not the leading `:`) expands to
+  `renovate-config-default:webapp`
 
 ## Supported config syntax
 
@@ -23,7 +34,8 @@ In human-understandable form, the rules are:
 @somescope
 ```
 
-This will resolve to use the preset `default` in the npm package `@somescope/renovate-config`.
+This will resolve to use the preset `default` in the npm package
+`@somescope/renovate-config`.
 
 ### Scoped with package name
 
@@ -31,7 +43,8 @@ This will resolve to use the preset `default` in the npm package `@somescope/ren
 @somescope/somepackagename
 ```
 
-This will resolve to use the preset `default` in the npm package `@somescope/somepackagename`.
+This will resolve to use the preset `default` in the npm package
+`@somescope/somepackagename`.
 
 ### Scoped with preset name
 
@@ -39,7 +52,8 @@ This will resolve to use the preset `default` in the npm package `@somescope/som
 @somescope:webapp
 ```
 
-This will resolve to use the preset `webapp` in the npm package `@somescope/renovate-config`.
+This will resolve to use the preset `webapp` in the npm package
+`@somescope/renovate-config`.
 
 ### Scoped with params
 
@@ -47,7 +61,8 @@ This will resolve to use the preset `webapp` in the npm package `@somescope/reno
 @somescope(eslint, stylelint)
 ```
 
-This will resolve to use the preset `default` in the npm package `@somescope/renovate-config` and pass the parameters `eslint` and `stylelint`.
+This will resolve to use the preset `default` in the npm package
+`@somescope/renovate-config` and pass the parameters `eslint` and `stylelint`.
 
 ### Scoped with preset name and params
 
@@ -55,7 +70,8 @@ This will resolve to use the preset `default` in the npm package `@somescope/ren
 @somescope:webapp(eslint, stylelint)
 ```
 
-This will resolve to use the preset `webapp` in the npm package `@somescope/renovate-config` and pass the parameters `eslint` and `stylelint`.
+This will resolve to use the preset `webapp` in the npm package
+`@somescope/renovate-config` and pass the parameters `eslint` and `stylelint`.
 
 ### Scoped with package name and preset name
 
@@ -63,7 +79,8 @@ This will resolve to use the preset `webapp` in the npm package `@somescope/reno
 @somescope/somepackagename:webapp
 ```
 
-This will resolve to use the preset `webapp` in the npm package `@somescope/somepackagename`.
+This will resolve to use the preset `webapp` in the npm package
+`@somescope/somepackagename`.
 
 ### Scoped with package name and preset name and params
 
@@ -71,7 +88,8 @@ This will resolve to use the preset `webapp` in the npm package `@somescope/some
 @somescope/somepackagename:webapp(eslint, stylelint)
 ```
 
-This will resolve to use the preset `webapp` in the npm package `@somescope/somepackagename` and pass the parameters `eslint` and `stylelint`.
+This will resolve to use the preset `webapp` in the npm package
+`@somescope/somepackagename` and pass the parameters `eslint` and `stylelint`.
 
 ### Non-scoped short with preset name
 
@@ -81,7 +99,8 @@ Note: if using non-scoped packages, a preset name is mandatory.
 somepackagename:default
 ```
 
-This will resolve to use the preset `default` in the npm package `renovate-config-somepackagename`.
+This will resolve to use the preset `default` in the npm package
+`renovate-config-somepackagename`.
 
 ### Non-scoped short with preset name and params
 
@@ -91,7 +110,8 @@ Note: if using non-scoped packages, a preset name is mandatory.
 somepackagename:default(eslint)
 ```
 
-This will resolve to use the preset `default` in the npm package `renovate-config-somepackagename` with param `eslint`.
+This will resolve to use the preset `default` in the npm package
+`renovate-config-somepackagename` with param `eslint`.
 
 ### Non-scoped full with preset name
 
@@ -101,7 +121,8 @@ Note: if using non-scoped packages, a preset name is mandatory.
 renovate-config-somepackagename:default
 ```
 
-This will resolve to use the preset `default` in the npm package `renovate-config-somepackagename`.
+This will resolve to use the preset `default` in the npm package
+`renovate-config-somepackagename`.
 
 ### Non-scoped full with preset name and params
 
@@ -111,4 +132,5 @@ Note: if using non-scoped packages, a preset name is mandatory.
 renovate-config-somepackagename:default(eslint)
 ```
 
-This will resolve to use the preset `default` in the npm package `renovate-config-somepackagename` and param `eslint`.
+This will resolve to use the preset `default` in the npm package
+`renovate-config-somepackagename` and param `eslint`.
diff --git a/docs/status-checks.md b/docs/status-checks.md
index ead2798569..9e23bab92e 100644
--- a/docs/status-checks.md
+++ b/docs/status-checks.md
@@ -2,8 +2,17 @@
 
 ## unpublish-safe
 
-Renovate includes a status showing whether upgrades are "unpublish-safe". This is because [packages less than 24 hours old may be unpublished by their authors](https://docs.npmjs.com/cli/unpublish). We recommend you wait for this status check to pass before merging unless the upgrade is urgent, otherwise you may find that packages simply disappear from the npm registry, breaking your build.
+Renovate includes a status showing whether upgrades are "unpublish-safe". This
+is because
+[packages less than 24 hours old may be unpublished by their authors](https://docs.npmjs.com/cli/unpublish).
+We recommend you wait for this status check to pass before merging unless the
+upgrade is urgent, otherwise you may find that packages simply disappear from
+the npm registry, breaking your build.
 
-If you would like to disable this status check, add `"unpublishSafe": false` to your config.
+If you would like to disable this status check, add `"unpublishSafe": false` to
+your config.
 
-If you would like to delay creation of Pull Requests until after this check passes, then add `"prCreation": "not-pending"` to your config. This way the PR will only be created once the upgrades in the branch are at least 24 hours old because Renovate sets the status check to "pending" in the meantime.
+If you would like to delay creation of Pull Requests until after this check
+passes, then add `"prCreation": "not-pending"` to your config. This way the PR
+will only be created once the upgrades in the branch are at least 24 hours old
+because Renovate sets the status check to "pending" in the meantime.
diff --git a/package.json b/package.json
index b5db36b1d8..5bcb94fd2a 100644
--- a/package.json
+++ b/package.json
@@ -10,7 +10,7 @@
     "jest": "npm run clean-cache && cross-env NODE_ENV=test LOG_LEVEL=fatal jest",
     "lint-fix": "eslint --fix lib test",
     "lint": "eslint lib test",
-    "prettier": "prettier \"**/*.{js,json}\" --write",
+    "prettier": "prettier \"**/*.{js,json,md}\" --write",
     "start": "node lib/renovate",
     "test-dirty": "git diff --exit-code",
     "test": "npm run prettier -- --list-different && npm run lint && npm run jest",
diff --git a/readme.md b/readme.md
index 6b1746e445..78bce97a8b 100644
--- a/readme.md
+++ b/readme.md
@@ -12,22 +12,28 @@ Keep dependencies up-to-date.
 
 ## Why
 
--   Creates or updates Pull Requests for each dependency that needs updating
--   Discovers and processes all `package.json` files in repository (supports monorepo architecture including yarn workspaces)
--   Supports multiple major versions per-dependency at once
--   Configurable via file, environment, CLI, and `package.json`
--   Supports eslint-like preset configs for ease of use
--   Updates `yarn.lock` and `package-lock.json` files natively
--   Supports GitHub, GitLab and VSTS
--   Open source and can be self-hosted or used via GitHub App
+* Creates or updates Pull Requests for each dependency that needs updating
+* Discovers and processes all `package.json` files in repository (supports
+  monorepo architecture including yarn workspaces)
+* Supports multiple major versions per-dependency at once
+* Configurable via file, environment, CLI, and `package.json`
+* Supports eslint-like preset configs for ease of use
+* Updates `yarn.lock` and `package-lock.json` files natively
+* Supports GitHub, GitLab and VSTS
+* Open source and can be self-hosted or used via GitHub App
 
 ## Configuration Help
 
-If you would like help on your Renovate configuration, or simply get someone to review it, we have created a config-help repository https://github.com/renovateapp/config-help/issues where you can post an issue with your config.
+If you would like help on your Renovate configuration, or simply get someone to
+review it, we have created a config-help repository
+https://github.com/renovateapp/config-help/issues where you can post an issue
+with your config.
 
 ## GitHub App
 
-Renovate is now available as a free GitHub "App". Go to [https://github.com/apps/renovate](https://github.com/apps/renovate) to enable it now.
+Renovate is now available as a free GitHub "App". Go to
+[https://github.com/apps/renovate](https://github.com/apps/renovate) to enable
+it now.
 
 ## Install
 
@@ -37,33 +43,55 @@ $ npm install -g renovate
 
 ## Authentication
 
-You need to select a repository user for `renovate` to assume the identity of, and generate a Personal Access Token. It's strongly recommended that you use a dedicated "bot" account for this to avoid user confusion and to avoid the Renovate bot mistaking changes you have made or PRs you have raised for its own.
+You need to select a repository user for `renovate` to assume the identity of,
+and generate a Personal Access Token. It's strongly recommended that you use a
+dedicated "bot" account for this to avoid user confusion and to avoid the
+Renovate bot mistaking changes you have made or PRs you have raised for its own.
 
-You can find instructions for GitHub [here](https://help.github.com/articles/creating-an-access-token-for-command-line-use/) (select "repo" permissions)
+You can find instructions for GitHub
+[here](https://help.github.com/articles/creating-an-access-token-for-command-line-use/)
+(select "repo" permissions)
 
-You can find instructions for GitLab [here](https://docs.gitlab.com/ee/api/README.html#personal-access-tokens).
+You can find instructions for GitLab
+[here](https://docs.gitlab.com/ee/api/README.html#personal-access-tokens).
 
-You can find instructions for VSTS [vsts](https://www.visualstudio.com/en-us/docs/integrate/get-started/authentication/pats).
+You can find instructions for VSTS
+[vsts](https://www.visualstudio.com/en-us/docs/integrate/get-started/authentication/pats).
 
-This token needs to be configured via file, environment variable, or CLI. See [docs/configuration.md](docs/configuration.md) for details.
-The simplest way is to expose it as `GITHUB_TOKEN` or `GITLAB_TOKEN` or `VSTS_TOKEN`.
+This token needs to be configured via file, environment variable, or CLI. See
+[docs/configuration.md](docs/configuration.md) for details. The simplest way is
+to expose it as `GITHUB_TOKEN` or `GITLAB_TOKEN` or `VSTS_TOKEN`.
 
 ## Usage
 
 Run `renovate --help` for usage details.
 
-Note: The first time you run `renovate` on a repository, it will not upgrade any dependencies. Instead, it will create a Pull Request (Merge Request if GitLab) called 'Configure Renovate' and commit a default `renovate.json` file to the repository. This PR can be close unmerged if the default settings are fine for you. Also, this behaviour can be disabled if you set the `onboarding` configuration option to `false` before running.
+Note: The first time you run `renovate` on a repository, it will not upgrade any
+dependencies. Instead, it will create a Pull Request (Merge Request if GitLab)
+called 'Configure Renovate' and commit a default `renovate.json` file to the
+repository. This PR can be close unmerged if the default settings are fine for
+you. Also, this behaviour can be disabled if you set the `onboarding`
+configuration option to `false` before running.
 
 ## Deployment
 
-See [deployment docs](https://github.com/renovateapp/renovate/blob/master/docs/deployment.md) for details.
+See
+[deployment docs](https://github.com/renovateapp/renovate/blob/master/docs/deployment.md)
+for details.
 
 ## Configuration
 
-The [Configuration](https://github.com/renovateapp/renovate/blob/master/docs/configuration.md) and [Configuration FAQ](https://github.com/renovateapp/renovate/blob/master/docs/faq.md) documents should be helpful.
+The
+[Configuration](https://github.com/renovateapp/renovate/blob/master/docs/configuration.md)
+and
+[Configuration FAQ](https://github.com/renovateapp/renovate/blob/master/docs/faq.md)
+documents should be helpful.
 
-You can also raise an issue in https://github.com/renovateapp/config-help if you'd like to get your config reviewed or ask any questions.
+You can also raise an issue in https://github.com/renovateapp/config-help if
+you'd like to get your config reviewed or ask any questions.
 
 ## Design Decisions
 
-See [design decisions doc](https://github.com/renovateapp/renovate/blob/master/docs/design-decisions.md) for details.
+See
+[design decisions doc](https://github.com/renovateapp/renovate/blob/master/docs/design-decisions.md)
+for details.
-- 
GitLab