From 75ab3b14b718ef7914bec1a37be9de2b518d07c0 Mon Sep 17 00:00:00 2001
From: "renovate[bot]" <renovate[bot]@users.noreply.github.com>
Date: Tue, 27 Feb 2018 15:39:56 +0100
Subject: [PATCH] chore: update dependency prettier to v1.11.0 (#1566)
* chore: update dependency prettier to v1.11.0
* update prettier results
---
docs/faq.md | 18 ++++++++---------
package.json | 2 +-
.../_posts/2017-07-26-dependency-pinning.md | 8 ++++----
.../docs/_posts/2017-08-18-config-presets.md | 4 ++--
.../2017-10-05-configuration-options.md | 14 ++++++-------
.../docs/_posts/2017-10-06-noise-reduction.md | 10 +++++-----
website/docs/_posts/2017-11-10-docker.md | 18 ++++++++---------
website/docs/_posts/2017-12-05-node.md | 10 +++++-----
website/docs/_posts/2017-12-15-bazel.md | 20 +++++++++----------
.../_posts/2017-12-28-updating-rebasing.md | 4 ++--
website/docs/_posts/2018-01-20-faq.md | 8 ++++----
yarn.lock | 6 +++---
12 files changed, 61 insertions(+), 61 deletions(-)
diff --git a/docs/faq.md b/docs/faq.md
index 4de37b3824..94d2856193 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 8620212c4f..c90dd71763 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 d8f2b701ac..0da86b2672 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 d1c8b30caa..d0c2fbe3e8 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 bdd1d8ff65..a7b7e63aa4 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 12ebb5360a..56c3877769 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 afaa33498e..4f5eebf6db 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 b9366d1a27..46f93c932e 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 098f4bcbfc..dff86f95ba 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 a4e0db89bc..03dc54d5ed 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 51545e71ad..79536c02a0 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 a8e7502fa5..e7e4a8e378 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"
--
GitLab