From a43e972c0f3791e20bafe1d4555b6a3ba33ab60c Mon Sep 17 00:00:00 2001
From: "renovate[bot]" <renovate[bot]@users.noreply.github.com>
Date: Mon, 28 May 2018 09:26:22 +0200
Subject: [PATCH] chore: update dependency prettier to v1.13.0 (#2030)
* chore: update dependency prettier to v1.13.0
* run prettier
---
.github/issue_template.md | 14 +++++++-------
docs/adding-a-package-manager.md | 6 +++---
docs/configuration.md | 10 +++++-----
docs/design-decisions.md | 20 +++++++++----------
docs/shareable-configs.md | 14 +++++++-------
package.json | 2 +-
readme.md | 22 ++++++++++-----------
website/docs/configuration-options.md | 24 +++++++++++------------
website/docs/configure-renovate.md | 10 +++++-----
website/docs/data-security.md | 28 +++++++++++++--------------
website/docs/dependency-pinning.md | 12 ++++++------
website/docs/docker.md | 4 ++--
website/docs/faq.md | 26 ++++++++++++-------------
website/docs/node.md | 6 +++---
website/docs/noise-reduction.md | 24 +++++++++++------------
website/docs/semantic-commits.md | 4 ++--
website/docs/updating-rebasing.md | 4 ++--
yarn.lock | 6 +++---
18 files changed, 118 insertions(+), 118 deletions(-)
diff --git a/.github/issue_template.md b/.github/issue_template.md
index 52b3a8906e..7924280a83 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 727b8b5ac8..a1797aaba5 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 7ac65194a5..de71d48a2f 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 80e57a0cf4..2cf17ac13c 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 ba3552fea5..80df39d1c5 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 91b5e10b80..caac63ac87 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 baef38716d..8a024c4790 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 19ef16a0ca..cf0a9859dd 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 e5068152e6..d67d09c094 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 3835aa94d2..93ed36f9f9 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 08b6d1c039..320997dc66 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 73b898b307..2c20d87eb6 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 e9e3eef652..0636d0eb6d 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 fe99a3562b..d01def0eaa 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 f790f2819a..463882390f 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 d0e23cff41..52e5706525 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 838cb830d0..f3b6eccb49 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 79edeb911e..a939d7557b 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"
--
GitLab