`Adds a config validation check for timezone, checking it against the list in moment-timezome.js`. Configs with invalid timezones will raise a configuration error.
Closes#1483
Upgrade ranges to latest version even if latest version satisfies existing range.
| name | value |
| ------- | ------- |
| type | boolean |
| default | false |
By default, Renovate assumes that if you are using ranges then it's because you want them to be wide/open. As such, Renovate won't deliberately "narrow" the range by increasing the semver value inside.
For example, if your `package.json` specifies a value for `left-pad` of `^1.0.0` and the latest version on npmjs is `1.2.0`, then Renovate won't change anything. If instead you'd prefer to be updated to `^1.2.0` in cases like this, then set `upgradeInRange` to `true` in your Renovate config.
This feature supports simple caret (`^`) and tilde (`~`) ranges only, like `^1.0.0` and `~1.0.0`. It is not compatible with `pinVersions=true`.
Closes#1607
Adds initial support for `.nvmrc` renovation. If the existing value is a fully-specified semver version then it will be upgraded, otherwise left alone.
Closes#1270
A semver range defining allowed versions for dependencies
| name | value |
| ---- | ------ |
| type | string |
Use this - usually within a packageRule - to limit how far to upgrade a dependency. For example, if you wish to upgrade to angular v1.5 but not to `angular` v1.6 or higher, you could defined this to be `<= 1.5` or `< 1.6.0`:
```
"packageRules": [{
"packageNames": ["angular"],
"allowedVersions": "<=1.5"
}]
```
in GitLab, a PR may be open while the branch itself has been removed. We cant just assume that the branch exists because the PR does, even if it’s an edge case.
Before, we were attempting to rebase edited branches if renovate.json was the only modified file. This “lost” the committer information - which seemed ok - but it also meant that on the subsequent run it then assumed Renovate was the only committer. Now we don’t rebase edited onboarding branches anymore.
Closes#1360
Adds configuration option `onboardingConfig` that allows the default onboarding config to be extended or replaced via `config.js` or env configuration.
Closes#1521
* Revert "fix: disable reusing existing package-lock.json when upgrading (#1530)"
This reverts commit 2728e39963.
* switch from —package-lock-only to —ignore-scripts
Removing `--package-lock-only` option from npm installs due to https://github.com/npm/npm/issues/19852
Pretty sure this fixes#1495
Rhys Arkins