diff --git a/docs/faq.md b/docs/faq.md
index 4de37b382499d7f59a7c3be7d34aec0e3aa05387..94d2856193f2dde3b46e2100e72e9967d29aa977 100644
--- a/docs/faq.md
+++ b/docs/faq.md
@@ -20,15 +20,15 @@ private modules is to make sure the appropriate credentials are in `.npmrc` or
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
diff --git a/package.json b/package.json
index 8620212c4f3b8219a2d07926f18314ef5dbce77e..c90dd71763281be99db9564816baf048a9c1700b 100644
--- a/package.json
+++ b/package.json
@@ -98,7 +98,7 @@
"jest": "22.4.2",
"mockdate": "2.0.2",
"nock": "9.2.2",
- "prettier": "1.10.2",
+ "prettier": "1.11.0",
"semantic-release": "12.4.1"
},
"files": [
diff --git a/website/docs/_posts/2017-07-26-dependency-pinning.md b/website/docs/_posts/2017-07-26-dependency-pinning.md
index d8f2b701acc7330652302296c5e52710a3cc7b5c..0da86b267299b951a9b3f5ddeb5d40d29e9c0773 100644
--- a/website/docs/_posts/2017-07-26-dependency-pinning.md
+++ b/website/docs/_posts/2017-07-26-dependency-pinning.md
@@ -154,10 +154,10 @@ But certainly "does it give a false sense of securty" is not a question we can r
We recommend:
-1. Any apps (web or node.js) that aren't `require()`'d by other packages should pin all types of dependencies for greatest reliability/predictability.
-2. Browser or dual browser/node.js libraries that are consumed/`required()`'d by others should keep using semver ranges for `dependencies` but can use pinned dependencies for `devDependencies`.
-3. Node.js-only libraries can consider pinning all dependencies, because application size/duplicate dependencies are not as much a concern in node.js compared to the browser. Of course, don't do that if your library is a micro one likely to be consumed in disk-sensitive environments.
-4. Use a lock file.
+1. Any apps (web or node.js) that aren't `require()`'d by other packages should pin all types of dependencies for greatest reliability/predictability.
+2. Browser or dual browser/node.js libraries that are consumed/`required()`'d by others should keep using semver ranges for `dependencies` but can use pinned dependencies for `devDependencies`.
+3. Node.js-only libraries can consider pinning all dependencies, because application size/duplicate dependencies are not as much a concern in node.js compared to the browser. Of course, don't do that if your library is a micro one likely to be consumed in disk-sensitive environments.
+4. Use a lock file.
As noted earlier, when you pin dependencies then you will see an increase in the raw volume of dependency updates, compared to if you use ranges. If/when this starts bothering you, add Renovate rules to reduce the volume, such as scheduling updates, grouping them, or automerging "safe" ones.
diff --git a/website/docs/_posts/2017-08-18-config-presets.md b/website/docs/_posts/2017-08-18-config-presets.md
index d1c8b30caa437aae1da5b2a56c00220418b53c2c..d0c2fbe3e8fc94ddf1b779e267737a857c531aaa 100644
--- a/website/docs/_posts/2017-08-18-config-presets.md
+++ b/website/docs/_posts/2017-08-18-config-presets.md
@@ -14,8 +14,8 @@ Renovate supports an `eslint`-like approach to shareable configs, which we usual
The main reason for supporting preset configs is to decrease duplication:
-1. You shouldn't need copy/paste config across all your repositories
-2. You shouldn't need to reinvent any config "wheels" that others have invented before
+1. You shouldn't need copy/paste config across all your repositories
+2. You shouldn't need to reinvent any config "wheels" that others have invented before
A further reason was to make Renovate configuration "self-documenting", by adding the `"description"` field to all preset configs.
diff --git a/website/docs/_posts/2017-10-05-configuration-options.md b/website/docs/_posts/2017-10-05-configuration-options.md
index bdd1d8ff655462aa0f6fe6d09b036386366159da..a7b7e63aa4d0f2d68d1fe6b2988f86241edecfa9 100644
--- a/website/docs/_posts/2017-10-05-configuration-options.md
+++ b/website/docs/_posts/2017-10-05-configuration-options.md
@@ -764,11 +764,11 @@ Rate limit PRs to maximum x created per hour. 0 (default) means no limit.
This setting - if enabled - helps slow down Renovate, particularly during the onboarding phase. What may happen without this setting is:
-1. Onboarding PR is created
-2. User merges onboarding PR to activate Renovate
-3. Renovate creates a "Pin Dependencies" PR (if necessary)
-4. User merges Pin PR
-5. Renovate then creates every single upgrade PR necessary - potentially dozens
+1. Onboarding PR is created
+2. User merges onboarding PR to activate Renovate
+3. Renovate creates a "Pin Dependencies" PR (if necessary)
+4. User merges Pin PR
+5. Renovate then creates every single upgrade PR necessary - potentially dozens
The above can result in swamping CI systems, as well as a lot of retesting if branches need to be rebased every time one is merged. Instead, if `prHourlyLimit` is set to a value like 1 or 2, it will mean that Renovate creates at most that many new PRs within each hourly period (:00-:59). So the project should still result in all PRs created perhaps within the first 24 hours maximum, but at a rate that may allow users to merge them once they pass tests. It does not place a limit on the number of _concurrently open_ PRs - only on the rate they are created.
@@ -1050,8 +1050,8 @@ npm-only.
Renovate's "auto" strategy for updating versions is like this:
-1. If the existing version already ends with an "or" operator - e.g. `"^1.0.0 || ^2.0.0"` - then Renovate will widen it, e.g. making it into `"^1.0.0 || ^2.0.0 || ^3.0.0"`.
-2. Otherwise, replace it. e.g. `"^2.0.0"` would be replaced by `"^3.0.0"`
+1. If the existing version already ends with an "or" operator - e.g. `"^1.0.0 || ^2.0.0"` - then Renovate will widen it, e.g. making it into `"^1.0.0 || ^2.0.0 || ^3.0.0"`.
+2. Otherwise, replace it. e.g. `"^2.0.0"` would be replaced by `"^3.0.0"`
You can override logic either way, by setting it to `replace` or `widen`. e.g. if the currentVersion is `"^1.0.0 || ^2.0.0"` but you configure `versionStrategy=replace` then the result will be `"^3.0.0"`.
diff --git a/website/docs/_posts/2017-10-06-noise-reduction.md b/website/docs/_posts/2017-10-06-noise-reduction.md
index 12ebb5360a2a914a499514d54280b3e3c88de0e4..56c3877769724025972c8c2775ad59099c2d375d 100644
--- a/website/docs/_posts/2017-10-06-noise-reduction.md
+++ b/website/docs/_posts/2017-10-06-noise-reduction.md
@@ -43,9 +43,9 @@ Another example of adjusting schedules to fit with your workflow might be if you
**Caution**: You need to make sure you leave yourself and Renovate enough time in a week to actually get all your updating and merging done. There are multiple reasons why Renovate may need to "recreate" PRs after you merge another:
-1. Conflict with `package.json` (sometimes)
-2. Conflict with lock files (often)
-3. If you have configure Renovate or GitHub that PRs must always be kept up-to-date with master
+1. Conflict with `package.json` (sometimes)
+2. Conflict with lock files (often)
+3. If you have configure Renovate or GitHub that PRs must always be kept up-to-date with master
Any of the above reasons can lead to a Renovate branch being considered "stale" and then Renovate needs to rebase it off `master` before you can test and merge again, and Renovate won't do this until it's back in schedule.
@@ -138,7 +138,7 @@ As mentioned earlier. using lock files greatly increase the chance that merging
First of all, if you every have any ideas about how to make Renovate less noisy, please raise or comment on issues in the [main repository](https://github.com/renovateapp/renovate). Our philosophy is:
-1. Nearly everyone should probably use Renovate-like dependency update automation
-2. Over time, you should "see" Renovate less and less
+1. Nearly everyone should probably use Renovate-like dependency update automation
+2. Over time, you should "see" Renovate less and less
One of our hopes with preset configs is that a set of "sensible" configs can be maintained by the community that combine grouping, scheduling and automerging to reduce the amount of noise in repositories with little downside or increased risk. Such lists could be maintained and used somewhat like Adblock lists - kept up to date by maintainers but for the majority of users they are simply trusted/automatic/invisible.
diff --git a/website/docs/_posts/2017-11-10-docker.md b/website/docs/_posts/2017-11-10-docker.md
index afaa33498e1bf52cf0bd0b83807118d7fad0a3c9..4f5eebf6db41b41d64c9b38a8704df1f6024c459 100644
--- a/website/docs/_posts/2017-11-10-docker.md
+++ b/website/docs/_posts/2017-11-10-docker.md
@@ -12,10 +12,10 @@ Renovate supports upgrading dependencies in Docker's `Dockerfile` files.
## How It Works
-1. Renovate will search each repository for any files named (exactly) `Dockerfile`
-2. The first `FROM` line will parsed
-3. If no [digest](https://docs.docker.com/engine/reference/commandline/images/) is already in use then Renovate will raise a PR to "pin" that dependency to a Docker digest
-4. If the image tag in use "looks" like a semver (e.g. `node:8`, `node:8.9`, `node:8.9.0`, `node:8-onbuild`) then Renovate will look up the Docker registry to determine if any upgrades are available (e.g. `node:8.9.1`).
+1. Renovate will search each repository for any files named (exactly) `Dockerfile`
+2. The first `FROM` line will parsed
+3. If no [digest](https://docs.docker.com/engine/reference/commandline/images/) is already in use then Renovate will raise a PR to "pin" that dependency to a Docker digest
+4. If the image tag in use "looks" like a semver (e.g. `node:8`, `node:8.9`, `node:8.9.0`, `node:8-onbuild`) then Renovate will look up the Docker registry to determine if any upgrades are available (e.g. `node:8.9.1`).
## Digest Pinning
@@ -82,10 +82,10 @@ Add `"default:automergeDigest"` to your `extends` array. Also add `"default:auto
The following features are planned but not supported today:
-1. Multiple `FROM` lines in `Dockerfile`s
-2. `ARG` arguments in `Dockerfile` `FROM` lines
-3. Custom `Dockerfile` filenames (e.g. `Dockerfile-dev`)
-4. Custom Docker registries (only Docker Hub is currently supported)
-5. Docker Compose file support
+1. Multiple `FROM` lines in `Dockerfile`s
+2. `ARG` arguments in `Dockerfile` `FROM` lines
+3. Custom `Dockerfile` filenames (e.g. `Dockerfile-dev`)
+4. Custom Docker registries (only Docker Hub is currently supported)
+5. Docker Compose file support
If any of these features are important to you, please add a comment or at least a `+1` in Renovate's [Issues Tracker](https://github.com/renovateapp/renovate/issues?q=is%3Aopen+is%3Aissue+label%3A%23docker).
diff --git a/website/docs/_posts/2017-12-05-node.md b/website/docs/_posts/2017-12-05-node.md
index b9366d1a278fd6d1ee40e64fca429d5609c0eabf..46f93c932e6ebdbdc0a48e5d16e70898f3464cd0 100644
--- a/website/docs/_posts/2017-12-05-node.md
+++ b/website/docs/_posts/2017-12-05-node.md
@@ -12,11 +12,11 @@ Renovate supports upgrading Node.js versions in `.travis.yml` files.
## How It Works
-1. You must enable Node renovation explicitly in your `renovate.json`: `"node": { "enabled": true }`
-2. Optionally, configure a `supportPolicy` (otherwise, the default is LTS): `"supportPolicy": ["lts_latest", "current"]`
-3. Renovate will search repositories for a `.travis.yml` in the root directory
-4. Existing Node.js versions will be extracted from the `node_js` array if it exists
-5. Renovate will replace this with the correct versions array based on your configured `supportPolicy` (defaults to `"lts"`)
+1. You must enable Node renovation explicitly in your `renovate.json`: `"node": { "enabled": true }`
+2. Optionally, configure a `supportPolicy` (otherwise, the default is LTS): `"supportPolicy": ["lts_latest", "current"]`
+3. Renovate will search repositories for a `.travis.yml` in the root directory
+4. Existing Node.js versions will be extracted from the `node_js` array if it exists
+5. Renovate will replace this with the correct versions array based on your configured `supportPolicy` (defaults to `"lts"`)
## Support Policies
diff --git a/website/docs/_posts/2017-12-15-bazel.md b/website/docs/_posts/2017-12-15-bazel.md
index 098f4bcbfcb5797fdb5a7c9dbdae1484c5d56219..dff86f95ba99ea9880370be6b64d7c3cc0f2a191 100644
--- a/website/docs/_posts/2017-12-15-bazel.md
+++ b/website/docs/_posts/2017-12-15-bazel.md
@@ -12,18 +12,18 @@ Renovate supports upgrading dependencies in bazel `WORKSPACE` files.
## How It Works
-1. Bazel support is enabled automatically, so you do not have to explicitly configure it to be enabled
-2. Renovate will search repositories for any `WORKSPACE` files in the repository
-3. Existing dependencies will be extracted from `git_repository` and `http_archive` declarations
-4. Renovate will replace any old versions with the latest version available
+1. Bazel support is enabled automatically, so you do not have to explicitly configure it to be enabled
+2. Renovate will search repositories for any `WORKSPACE` files in the repository
+3. Existing dependencies will be extracted from `git_repository` and `http_archive` declarations
+4. Renovate will replace any old versions with the latest version available
## git_repository
Renovate will update any `git_repository` declaration that contains the following:
-1. name
-2. remote matching `https://github.com/<owner>/<repo>.git`
-3. tag using a valid semver
+1. name
+2. remote matching `https://github.com/<owner>/<repo>.git`
+3. tag using a valid semver
Example:
@@ -41,9 +41,9 @@ New versions will be detected using the list of **tags** for that repository on
Renovate will update any `http_archive` declaration that contains the following:
-1. name
-2. url matching `https://github.com/<owner>/<repo>/releases/download/<semver>/<repo>.tar.gz`
-3. sha256
+1. name
+2. url matching `https://github.com/<owner>/<repo>/releases/download/<semver>/<repo>.tar.gz`
+3. sha256
Example:
diff --git a/website/docs/_posts/2017-12-28-updating-rebasing.md b/website/docs/_posts/2017-12-28-updating-rebasing.md
index a4e0db89bc3b009e6de3fda3ce0bbdd2585e06cc..03dc54d5ed71cc56f7ab04aacb1482082cee3680 100644
--- a/website/docs/_posts/2017-12-28-updating-rebasing.md
+++ b/website/docs/_posts/2017-12-28-updating-rebasing.md
@@ -24,8 +24,8 @@ If new commits to the base branch - such as merging another Renovate PR - result
There are two cases where Renovate will rebase its branches off the base branch every time they are out of date:
-1. If you manually configure `"rebaseStalePrs"` to be true.
-2. If you have enabled "Require branches to be up to date before merging" on GitHub protected branches settings
+1. If you manually configure `"rebaseStalePrs"` to be true.
+2. If you have enabled "Require branches to be up to date before merging" on GitHub protected branches settings
In that case Renovate PRs will be continuously rebased off the repository's base branch whenever necessary, even if the PRs are not conflicted.
diff --git a/website/docs/_posts/2018-01-20-faq.md b/website/docs/_posts/2018-01-20-faq.md
index 51545e71ad466791610a64282c4a941b65ff344a..79536c02a0450c7a28fb856cb29b29ad71ad53db 100644
--- a/website/docs/_posts/2018-01-20-faq.md
+++ b/website/docs/_posts/2018-01-20-faq.md
@@ -146,10 +146,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.
diff --git a/yarn.lock b/yarn.lock
index a8e7502fa509ef2fe5632ee956b54d6ea08ed517..e7e4a8e3780500ae0019ef0008d2433b2aa385ef 100644
--- a/yarn.lock
+++ b/yarn.lock
@@ -4453,9 +4453,9 @@ preserve@^0.2.0:
version "0.2.0"
resolved "https://registry.yarnpkg.com/preserve/-/preserve-0.2.0.tgz#815ed1f6ebc65926f865b310c0713bcb3315ce4b"
-prettier@1.10.2:
- version "1.10.2"
- resolved "https://registry.yarnpkg.com/prettier/-/prettier-1.10.2.tgz#1af8356d1842276a99a5b5529c82dd9e9ad3cc93"
+prettier@1.11.0:
+ version "1.11.0"
+ resolved "https://registry.yarnpkg.com/prettier/-/prettier-1.11.0.tgz#c024f70cab158c993f50fc0c25ffe738cb8b0f85"
pretty-format@^22.4.0:
version "22.4.0"