diff --git a/lib/config/definitions.js b/lib/config/definitions.js
index dd5999e707e6abe7dbfc67e80534974c85bbf6a3..31777d1944fa0574f7ef969a05427c5c1448bcb9 100644
--- a/lib/config/definitions.js
+++ b/lib/config/definitions.js
@@ -239,7 +239,7 @@ const options = [
},
{
name: 'npmToken',
- description: 'npm token used for autnenticating with the default registry',
+ description: 'npm token used for authenticating with the default registry',
stage: 'branch',
type: 'string',
},
@@ -286,7 +286,7 @@ const options = [
{
name: 'baseBranches',
description:
- 'An array of one or more custom base branches to be renovated. If left empty, the default branch will be renovate',
+ 'An array of one or more custom base branches to be renovated. If left empty, the default branch will be renovated',
type: 'list',
stage: 'package',
cli: false,
diff --git a/website/docs/configuration-options.md b/website/docs/configuration-options.md
index 117f1b68abed5b67c9c34c861ed8386fa7d0d63e..5c73a013a7b79aabba0008163e975723a7afbb84 100644
--- a/website/docs/configuration-options.md
+++ b/website/docs/configuration-options.md
@@ -90,7 +90,7 @@ This field is combined with `branchPrefix` and `managerBranchPrefix` to form the
Set this value to 'patch', 'minor' or 'major' to have Renovate update the version in your edited `package.json`. e.g. if you wish Renovate to always increase the target `package.json` version with a patch update, set this to `patch`.
-You can also set this field to `"mirror:x"` where `x` is the name of a package in the `package.json`. Doing so means that the `package.json` `version` field will mirror whatever is the version for `x` dependened on. Make sure that version is a pinned version of course, as otherwise it won't be valid.
+You can also set this field to `"mirror:x"` where `x` is the name of a package in the `package.json`. Doing so means that the `package.json` `version` field will mirror whatever the version is that `x` depended on. Make sure that version is a pinned version of course, as otherwise it won't be valid.
## circleci
@@ -643,7 +643,7 @@ The above can result in swamping CI systems, as well as a lot of retesting if br
## prNotPendingHours
-If you set `prCreation=not-pending`, then Renovate will wait until tests are non-pending (all pass or at least one fails) before creating PRs. However there are cases where PRs may remainin pending state forever, e.g. absence of tests or status checks that are set to pending indefinitely. Therefore we set an upper limit - default 24 hours - for how long we wait until creating a PR. Note also this is the same length of time as for Renovate's own `unpublishSafe` status check for npm.
+If you set `prCreation=not-pending`, then Renovate will wait until tests are non-pending (all pass or at least one fails) before creating PRs. However there are cases where PRs may remain in pending state forever, e.g. absence of tests or status checks that are set to pending indefinitely. Therefore we set an upper limit - default 24 hours - for how long we wait until creating a PR. Note also this is the same length of time as for Renovate's own `unpublishSafe` status check for npm.
## prTitle
@@ -703,7 +703,7 @@ Typically you shouldn't need to modify this setting.
## registryUrls
-This is only necessary in case you need to manually configure a registry URL to use for datasource lookups. Applies to PyPI (pip) only for now. Supports only one URL for now but is defined as a list for forwards compatibility.
+This is only necessary in case you need to manually configure a registry URL to use for datasource lookups. Applies to PyPI (pip) only for now. Supports only one URL for now but is defined as a list for forward compatibility.
## renovateFork
@@ -790,7 +790,7 @@ It is recommended that you leave this setting to true, because of the polite way
## separateMinorPatch
-By default, Renovate won't distinguish between "patch" (e.g. 1.0.x) and "minor" (e.g. 1.x.0) releases - groups them together. e.g. if you are running version 1.0.0 of a package and both versions 1.0.1 and 1.1.0 are available then Renovate will raise a single PR for version 1.1.0. If you wish to distinguish between patch and minor upgrades, for example if you wish to automerge patch but not minor, then you can set this option to `true`.
+By default, Renovate won't distinguish between "patch" (e.g. 1.0.x) and "minor" (e.g. 1.x.0) releases - it groups them together. E.g., if you are running version 1.0.0 of a package and both versions 1.0.1 and 1.1.0 are available then Renovate will raise a single PR for version 1.1.0. If you wish to distinguish between patch and minor upgrades, for example if you wish to automerge patch but not minor, then you can set this option to `true`.
## separateMultipleMajor
@@ -798,7 +798,7 @@ Set this to true if you wish to receive one PR for every separate major version
## statusCheckVerify
-This feature is added for people migrating from alternative services who are used to seeing a "verify" status check on PRs. If you'd like to use this then go ahead, but otherwise we recommend it's more secure to look for Renovate's [GPG Verified Commits](https://github.com/blog/2144-gpg-signature-verification) instead, because those cannot be spoofed by any other person or service (unlike status checks).
+This feature is added for people migrating from alternative services who are used to seeing a "verify" status check on PRs. If you'd like to use this then go ahead, but otherwise it's more secure to look for Renovate's [GPG Verified Commits](https://github.com/blog/2144-gpg-signature-verification) instead, because those cannot be spoofed by any other person or service (unlike status checks).
## supportPolicy
@@ -842,7 +842,7 @@ Note: Travis renovation is disabled by default as we cannot be sure of which com
It is not known by many that npm package authors and collaborators can _delete_ an npm version if it is less than 24 hours old. e.g. version 1.0.0 might exist, then version 1.1.0 is released, and then version 1.1.0 might get deleted hours later. This means that version 1.1.0 essentially "disappears" and 1.0.0 returns to being the "latest". If you have installed 1.1.0 during that time then your build is essentially broken.
-This setting `unpublishSafe` enabled will add a `renovate/unpublish-safe` status check with value pending to every branch to warn you about this possibility. It can be handy when used with the `prCreation` = `not-pending` configuration option - that way you won't get the PR raised until after a patch is 24 hours old or more.
+Enabling `unpublishSafe` will add a `renovate/unpublish-safe` status check with value pending to every branch to warn you about this possibility. It can be handy when used with the `prCreation` = `not-pending` configuration option - that way you won't get the PR raised until after a patch is 24 hours old or more.
## unstablePattern
@@ -856,7 +856,7 @@ This field is currently used by some config prefixes.
When schedules are in use, it generally means "no updates". However there are cases where updates might be desirable - e.g. if you have set prCreation=not-pending, or you have rebaseStale=true and master branch is updated so you want Renovate PRs to be rebased.
-This is default true, meaning that Renovate will perform certain "desirable" updates to _existing_ PRs even when outside of schedule. If you wish to disable all updates outside of scheduled hours then set this field to false.
+This defaults to true, meaning that Renovate will perform certain "desirable" updates to _existing_ PRs even when outside of schedule. If you wish to disable all updates outside of scheduled hours then set this field to false.
## vulnerabilityAlerts