.dockerignore

+*
+!package.json
+!yarn.lock
+!hooks
+!lib

.eslintrc.js

@@ -5,9 +5,11 @@ module.exports = {
   extends: ['airbnb-base', 'prettier'],
   plugins: ['import', 'promise'],
   rules: {
+    'require-await': 'error',
     'no-use-before-define': 0,
     'no-restricted-syntax': 0,
     'no-await-in-loop': 0,
+    'prefer-template': 'off',
     'promise/always-return': 'error',
     'promise/no-return-wrap': 'error',
     'promise/param-names': 'error',

.github/contributing.md

+# Contributing
+
+## Security
+
+If you think you've found a **security issue**, please do not mention it in this repository. Instead, email security@renovateapp.com with as much details as possible so that it can be handled confidentially.
+
+## Support
+
+If you have a **configuration question**, please create an issue in https://github.com/renovateapp/config-help
+
+## Bug Reports and Feature Requests
+
+If you've found a **bug** or have a **feature request** then please create an issue here (but search first in case it already exists).
+
+## Code
+
+If you would like to fix a bug or implement a feature, please fork the repository and create a Pull Request. More information on getting set up locally can be found in [docs/local-development.md](https://github.com/renovateapp/renovate/blob/master/docs/local-development.md).
+
+Before you start any Pull Request, it's recommended that you create an issue to discuss
+first if you have any doubts about requirement or implementation. That way you can be sure that the maintainer(s)
+agree on what to change and how, and you can hopefully get a quick merge
+afterwards. Also, let the maintainers know that you plan to work on a particular issue so that no one else starts any duplicate work.
+
+Pull Requests can only be merged once all status checks are green, which means `yarn test` passes, and coverage is 100%.
+
+## Legal
+
+By submitting a Pull Request, you disavow any rights or claims to any changes submitted to the Renovate project and assign the copyright of those changes to Key Location Pte Ltd.
+
+If you cannot or do not want to reassign those rights (your employment contract for your employer may not allow this), you should not submit a PR. Open an issue and someone else can do the work.
+
+This is a legal way of saying "If you submit a PR to us, that code becomes ours". 99.9% of the time that's what you intend anyways; we hope it doesn't scare you away from contributing.

.github/issue_template.md

+<!--
+    Is this about a security problem?
+    DO NOT RAISE AN ISSUE - please email security@renovateapp.com instead
+
+    Is this question about config help?
+    If so, please open an issue in https://github.com/renovateapp/config-help instead
+-->
+
+#### This is a:
+
+* [ ] 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
+
+#### Please describe the issue:

.gitignore

@@ -6,3 +6,5 @@
 .DS_Store
 .cache
 /*.log
+/.vscode
+/.idea

.travis.yml

+notifications:
+  email: false
+
+language: node_js
+
+node_js:
+  - "8"
+
+sudo: false
+
+branches:
+  only:
+  - master
+
+if: tag IS blank
+
+before_install:
+  - curl -o- -L https://yarnpkg.com/install.sh | bash
+  - export PATH="$HOME/.yarn/bin:$PATH"
+
+cache:
+  yarn: true
+  directories:
+    - ".cache"
+    - ".eslintcache"
+    - "node_modules"
+
+script:
+  - yarn run prettier -- --list-different
+  - yarn run lint
+  - yarn run jest --maxWorkers=4
+
+after_success:
+  - yarn run codecov
+
+deploy:
+  provider: script
+  script: yarn run semantic-release
+  skip_cleanup: true
+  on:
+    branch: master

Dockerfile

+FROM node:8.10.0-alpine@sha256:a55d3e87802b2a8464b3bfc1f8c3c409f89e9b70a31f1dccce70bd146501f1a0
+
+LABEL maintainer="Rhys Arkins <rhys@arkins.net>"
+LABEL name="renovate"
+
+WORKDIR /src
+
+RUN apk add --quiet --no-cache git openssh-client
+COPY package.json .
+COPY yarn.lock .
+RUN yarn install --production && yarn cache clean
+COPY lib ./lib
+RUN chown -R node:node /src
+USER node
+
+ENTRYPOINT ["node", "/src/lib/renovate.js"]
+CMD ["--help"]

Procfile

-renovate: yarn run start-raw
+renovate: yarn start
 web: node bin/heroku/web.js

bin/clean-cache.js

+const fs = require('fs-extra');
+const os = require('os');
+
+(async () => {
+  await fs.remove(os.tmpdir() + '/renovate-changelog-cache');
+  await fs.remove(os.tmpdir() + '/renovate-npm-cache');
+})();

bin/config-validator.js

+#!/usr/bin/env node
+
+const fs = require('fs-extra');
+const { validateConfig } = require('../lib/config/validation');
+
+/* eslint-disable no-console */
+
+let returnVal = 0;
+
+function validate(desc, config) {
+  const res = validateConfig(config);
+  if (res.errors.length) {
+    console.log(
+      `${desc} contains errors:\n\n${JSON.stringify(res.errors, null, 2)}`
+    );
+    returnVal = 1;
+  }
+  if (res.warnings.length) {
+    console.log(
+      `${desc} contains warnings:\n\n${JSON.stringify(res.warnings, null, 2)}`
+    );
+    returnVal = 1;
+  }
+}
+
+const renovateConfigFiles = [
+  'renovate.json',
+  '.renovaterc',
+  '.renovaterc.json',
+];
+for (const file of renovateConfigFiles) {
+  try {
+    const rawContent = fs.readFileSync(file, 'utf8');
+    console.log(`Validating ${file}`);
+    try {
+      const jsonContent = JSON.parse(rawContent);
+      validate(file, jsonContent);
+    } catch (err) {
+      console.log(`${file} is not valid JSON`);
+      returnVal = 1;
+    }
+  } catch (err) {
+    // file does not exist
+  }
+}
+try {
+  const pkgJson = JSON.parse(fs.readFileSync('package.json', 'utf8'));
+  if (pkgJson.renovate) {
+    console.log(`Validating package.json > renovate`);
+    validate('package.json > renovate', pkgJson.renovate);
+  }
+  if (pkgJson['renovate-config']) {
+    console.log(`Validating package.json > renovate-config`);
+    Object.values(pkgJson['renovate-config']).forEach(presetConfig => {
+      validate('package.json > renovate-config', presetConfig);
+    });
+  }
+} catch (err) {
+  // ignore
+}
+if (returnVal !== 0) {
+  process.exit(returnVal);
+}
+console.log('OK');

bin/update-configuration-table.js

-#!/usr/bin/env node
-const stringify = require('json-stringify-pretty-compact');
-
-const definitions = require('../lib/config/definitions');
-const defaultsParser = require('../lib/config/defaults');
-const cliParser = require('../lib/config/cli');
-const envParser = require('../lib/config/env');
-
-/* eslint-disable no-console */
-// Print table header
-console.log('## Configuration Options');
-console.log('');
-console.log('<table>');
-console.log('<tr>');
-const columns = [
-  'Name',
-  'Description',
-  'Type',
-  'Default value',
-  'Environment',
-  'CLI',
-];
-columns.forEach(column => {
-  console.log(`  <th>${column}</th>`);
-});
-console.log('</tr>');
-const options = definitions.getOptions();
-options.forEach(option => {
-  let optionDefault = defaultsParser.getDefault(option);
-  if (optionDefault !== '') {
-    optionDefault = `<pre>${stringify(optionDefault)}</pre>`;
-  }
-  let envName = envParser.getEnvName(option);
-  if (envName.length) {
-    envName = `\`${envName}\``;
-  }
-  let cliName = cliParser.getCliName(option);
-  if (cliName.length) {
-    cliName = `\`${cliName}\``;
-  }
-  console.log(
-    `<tr>
-  <td>\`${option.name}\`</td>
-  <td>${option.description}</td>
-  <td>${option.type}</td>
-  <td>${optionDefault}</td>
-  <td>${envName}</td>
-  <td>${cliName}<td>
-</tr>`
-  );
-});
-/* eslint-enable no-console */

bin/update-docs.sh

-#!/usr/bin/env bash
-
-perl -0777 -i -pe 's/\n  Usage:.*package-test\n/`node dist\/renovate --help`/se' docs/configuration.md
-perl -0777 -i -pe 's/## Configuration Options.*//se' docs/configuration.md
-node bin/update-configuration-table.js >> docs/configuration.md

circle.yml

-machine:
-  environment:
-    PATH: "${PATH}:${HOME}/${CIRCLE_PROJECT_REPONAME}/node_modules/.bin"
-    YARN_PATH: "$HOME/.yarn"
-  node:
-    version: 8
-
-dependencies:
-  pre:
-    - curl -o- -L https://yarnpkg.com/install.sh | bash -s -- --version 1.0.2
-    - yarn --version
-  override:
-    - yarn install --frozen-lockfile
-  cache_directories:
-    - ~/.cache
-    - ~/.yarn
-    - .cache
-
-test:
-  override:
-    - yarn test
-  post:
-    - bash <(curl -s https://codecov.io/bash)
-
-deployment:
-  npm:
-    branch: master
-    commands:
-      - yarn run semantic-release || true

contributing.md

-# Contributing
-
-Contributions are welcome and desirable, in the form of:
-
-- Bug reports (raise an issue)
-- Feature requests (raise an issue)
-- Code (submit a Pull Request)
-- Comments (comment on any of the above)
-
-Before you submit any code, it's recommended that you raise an issue first if you have any doubts. That way you can be sure that the maintainer(s) agree on what to change and how, and you can hopefully get a quick merge afterwards.
-
-## Running the source code locally
-
-After you have cloned the project, first check that it's running OK locally.
-
-First you will need to install dependencies. We use [yarn](https://github.com/yarnpkg/yarn) so run `yarn` instead of `npm install`.
-
-`renovate` supports node versions 6.9 and above. It is written using async/await so needs `babel` transpilation for node 6.
-
-If running in node 6, you need to run a transpiled version of the code. You can do this without an explicit transpilation step by running `yarn run start-babel`.
-Examples:
-
-```sh
-$ yarn run start-babel username/reponame
-$ LOG_LEVEL=verbose yarn run start-babel username/reponame
-$ yarn run start-babel -- --labels=foo username/reponame
-```
-
-If running on node 7, you can run just like the above, but use the `yarn run start-raw` command instead of `yarn run start-babel`.
-
-## Adding configuration options
-
-We wish to keep backwards-compatibility as often as possible, as well as make the code configurable, so most new functionality should be controllable via configuration options.
-Please see [Configuration docs](docs/configuration.md) for a list of current options.
-
-If you wish to add one, add it to `lib/config/definitions.js` and then run `yarn run update-docs`.
-
-## Running tests
-
-You can run `yarn test` locally to test your code. We also run Continuous Integration using CircleCI.
-
-We use [Prettier](https://github.com/prettier/prettier) for code formatting. If your code fails `yarn test` due to a `prettier` rule in `eslint` then it can be fixed by running `yarn run eslint-fix`;

docs/branches-commits.md

+# Branches and Commits Methodology
+
+## Multiple files per branch
+
+Renovate can/should update multiple files in the same branch/PR. e.g. it might be `package.json` and `yarn.lock`, or it might be multiple `package.json` files in a monorepo.
+
+## One commit per branch
+
+To keep things neat from a user perspective, and simplify things from Renovate's perspective, we aim to always use just one commit per branch, even when multiple files need updating.
+
+A positive side effect of this is that it allows us to have a shortcut rule of, "If there's only one commit in the branch then it's clean, otherwise it must have been edited by users and we should stop updating it".
+
+## Updating branches
+
+If files in an already-existing branch need updating (e.g. an even newer version has been released), then we still aim to have just one commit. We achieve this in different ways per-platform.
+
+#### GitHub
+
+For GitHub, we use the low-level `git`-based API to manually make the commits and essentially "force push" to the existing branch without closing it. It's important to do this way because if you close a branch with a PR attached then the PR will be automatically closed by GitHub.
+
+#### GitLab
+
+In GitLab, Merge Request are not automatically closed if you delete the associated branch, so that gives us more flexibility. Therefore the way we update a branch is simply to delete it and then create the branch + commits again, and GitLab immediately reassociates the new (single) commit with the existing PR.
+
+#### VSTS
+
+VSTS is implemented similarly to GitLab.

docs/deployment.md

 # Deployment
 
-Before deploying the script for scheduled runs, it's recommend you test your settings locally first.
+Before deploying the script for scheduled runs, it's recommend you test your
+settings locally first.
 
 ## Server cron
 
@@ -12,22 +13,23 @@ Install using `npm install -g`.
 
 ### Configuration
 
-At a minimum, you will need to configure the token and repository list.
-Simplest would be to specify both via CLI.
-Alternatively, configure the token via Environment Variable if you don't want it to show in any cron logs.
+At a minimum, you will need to configure the token and repository list. Simplest
+would be to specify both via CLI. Alternatively, configure the token via
+Environment Variable if you don't want it to show in any cron logs.
 
 Running daily should suit most people. At most, hourly.
 
 ## Heroku
 
-Heroku free dynos provide a good way to host this for free. Set it up with the following commands:
+Heroku free dynos provide a good way to host this for free. Set it up with the
+following commands:
 
 ### Installation
 
 The best way to deploy to Heroku is via git and Heroku CLI.
 
 ```
-$ git clone https://github.com/singapore/renovate
+$ git clone https://github.com/renovateapp/renovate
 $ cd renovate
 $ heroku create [app name]
 $ git push heroku master
@@ -40,9 +42,11 @@ You now need to set the token.
 ```
 $ heroku config:set GITHUB_TOKEN=[YourGitHubToken]
 ```
+
 (or use `GITLAB_TOKEN` if appropriate)
 
-You should also set any other [Configuration Options](configuration.md) you need.
+You should also set any other [Configuration Options](configuration.md) you
+need.
 
 The app should now be ready for testing.
 
@@ -50,12 +54,16 @@ The app should now be ready for testing.
 $ heroku run renovate [your/repo]
 ```
 
-Once you've verified the script ran successfully, it's time to set it up for automatic scheduling.
+Once you've verified the script ran successfully, it's time to set it up for
+automatic scheduling.
+
 ```
 $ heroku addons:create scheduler:standard
 $ heroku addons:open scheduler
 ```
 
-At this point you should have the Heroku Scheduler Dashboard open. Click "Add new job" and enter the same command as you ran previously (e.g. `renovate [your/repo]`). Adjust the frequency to hourly if you prefer, then click Save.
+At this point you should have the Heroku Scheduler Dashboard open. Click "Add
+new job" and enter the same command as you ran previously (e.g. `renovate [your/repo]`). Adjust the frequency to hourly if you prefer, then click Save.
 
-You can run `heroku logs` to check execution logs. Consider adjusting the scripts log level if you have problems (info -> verbose -> debug -> silly).
+You can run `heroku logs` to check execution logs. Consider adjusting the
+scripts log level if you have problems (info -> verbose -> debug -> silly).

docs/design-decisions.md

@@ -4,107 +4,133 @@ This file documents the design choices as well as configuration options.
 
 #### Stateless
 
-No state storage is needed on `renovate` or GitHub/GitLab apart from what you see publicly in GitHub (branches, Pull Requests). It therefore doesn't matter if you stop/restart the script and would even still work if you had it running from two different locations, as long as their configuration was the same.
+No state storage is needed on `renovate` or the source code repository apart
+from what you see publicly (branches, Pull Requests). It therefore doesn't
+matter if you stop/restart the script and would even still work if you had it
+running from two different locations, as long as their configuration was the
+same.
 
 #### API only
 
-So far, nothing we need to do requires a full `git clone` of the repository. e.g. we do not need to perform a git clone of the entire repository. Therefore, all operations are performed via the API.
+So far, nothing we need to do requires a full `git clone` of the repository.
+e.g. we do not need to perform a git clone of the entire repository. Therefore,
+all operations are performed via the API.
 
 ## Synchronous Operation
 
-The script current processes repositories, package files, and dependencies within them all synchronously.
+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.
 
 ## Multiple Configuration Methods
 
-The script supports multiple [configuration methods](configuration.md) concurrently, and processed in order of priority.
-This allows examples such as token configured via environment variable and labels configured via target `package.json`.
+The script supports multiple [configuration methods](configuration.md)
+concurrently, and processed in order of priority. This allows examples such as
+token configured via environment variable and labels configured via target
+`package.json`.
 
 ## Cascading Configuration
 
-Configuration options applied per-package override those applied per package-type, which override those per-repository, which override those which are global (all repositories).
-
-The following options can be configured down to a per-package type level:
-
-- Dependency Types
-- Ignored Dependencies
-
-The following options apply per-repository:
-
-- Token
-- Platform
-- Endpoint
-
-The following options apply globally:
-
-- Log Level
-
-The remaining configuration options can be applied per-package.
+Configuration options applied per-package (e.g. with package rules) override those applied per
+package-type, which override those per-repository, which override those which
+are global (all repositories).
 
 ## Automatic discovery of package.json locations
 
-Note: GitHub only.
-
-Default behaviour is to auto-discover all `package.json` locations in a repository and process them all.
-Doing so means that "monorepos" are supported by default.
-This can be overridden by the configuration option `packageFiles`, where you list the file paths manually (e.g. limit to just `package.json` in root of repository).
+Default behaviour is to auto-discover all `package.json` locations in a
+repository and process them all. Doing so means that "monorepos" are supported
+by default. This can be overridden by the configuration option `packageFiles`,
+where you list the file paths manually (e.g. limit to just `package.json` in
+root of repository).
 
 ## Separate Branches per dependency
 
-By default, `renovate` will maintain separate branches per-dependency. So if 20 dependencies need updating, there will be at least 20 branches/PRs. Although this may seem undesirable, it was considered even less desirable if all 20 were in the same Pull Request and it's up to the users to determine which dependency upgrade(s) caused the build to fail.
+By default, `renovate` will maintain separate branches per-dependency. So if 20
+dependencies need updating, there will be at least 20 branches/PRs. Although
+this may seem undesirable, it was considered even less desirable if all 20 were
+in the same Pull Request and it's up to the users to determine which dependency
+upgrade(s) caused the build to fail.
 
-However, it's still possible to override the default branch and PR name templates in such a way to produce a single branch for all dependencies. The `groupName` configuration option can be used at a repository level (e.g. give it the value `All`) and then all dependency updates will be in the same branch/PR.
+However, it's still possible to override the default branch and PR name
+templates in such a way to produce a single branch for all dependencies. The
+`groupName` configuration option can be used at a repository level (e.g. give it
+the value `All`) and then all dependency updates will be in the same branch/PR.
 
-## One PR per Major release
+## Separate Minor and Major PRs
 
-`renovate` will create multiple branches/PRs if multiple major branch upgrades 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).
+`renovate` will create multiple branches/PRs if both major and minor branch upgrades
+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 immediately.
-- 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 even if a new Major release exists
+* 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
+  or Patch updates.
+* Projects should get Minor and Patch updates for their current Major release
+  even if a new Major release exists
 
-This can be overriden via the config option `separateMajorReleases`.
+This can be overridden via the config option `separateMajorReleases`.
 
 ## Branch naming
 
-Branches are named like `renovate/webpack-1.x` instead of `renovate/webpack-1.2.0`.
+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` release happens
+* 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.
 
 ## Pull Request Recreation
 
-By default, the script does not create a new PR if it finds an identical one already closed. This allows users to close unwelcome upgrade PRs and worry about them being recreated every run. Typically this is most useful for major upgrades.
-This option is configurable.
+By default, the script does not create a new PR if it finds an identical one
+already closed. This allows users to close unwelcome upgrade PRs and worry about
+them being recreated every run. Typically this is most useful for major
+upgrades. This option is configurable.
 
 ## Range handling
 
-`renovate` prefers pinned dependency versions, instead of maintaining ranges. Even if the project is using tilde ranges, why not pin them for consistency if you're also using `renovate` every day?
+`renovate` prefers pinned dependency versions, instead of maintaining ranges.
+Even if the project is using tilde ranges, why not pin them for consistency if
+you're also using `renovate` every day?
 
 This is now configurable via the `pinVersions` configuration option.
 
 ## Rebasing Unmergeable Pull Requests
 
-Note: GitHub only. GitLab does not expose enough low level git API to allow this.
-
-With the default behaviour of one branch per dependency, it's often that case that a PR gets merge conflicts after an adjacent dependency update is merged. Although GitHub has added a web interface for simple merge conflicts, this is still annoying to resolve manually.
+With the default behaviour of one branch per dependency, it's often that case
+that a PR gets merge conflicts after an adjacent dependency update is merged.
+Although platforms often have a web interface for simple merge conflicts, this is
+still annoying to resolve manually.
 
-`renovate` will rebase any unmergeable branches and add the latest necessary commit on top of the most recent `master` commit.
+`renovate` will rebase any unmergeable branches and add the latest necessary
+commit on top of the most recent `master` commit.
 
-Note: `renovate` will only do this if the original branch hasn't been modified by anyone else.
+Note: `renovate` will only do this if the original branch hasn't been modified
+by anyone else.
 
 ## Suppressing string templates from CLI
 
-String templates (e.g. commit or PR name) are not configurable via CLI options, in order to not pollute the CLI help and make it unreadable. If you must configure via CLI, use an environment variable instead. e.g.
+String templates (e.g. commit or PR name) are not configurable via CLI options,
+in order to not pollute the CLI help and make it unreadable. If you must
+configure via CLI, use an environment variable instead. e.g.
 
 ```sh
 $ RENOVATE_BRANCH_NAME=foo renovate
 ```
 
 Alternatively, consider using a Configuration File.
+
+## Logging and error levels
+
+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

docs/faq.md

 # FAQ
 
-If you need a specific behaviour and it's not mentioned here - or it's more complicated - feel free to raise an [Issue](https://github.com/singapore/renovate/issues) - configuration questions are welcome in this repository.
-
-## What Is The Default Behaviour?
-
-Renovate will:
-
--   Look for configuration options in a `renovate.json` file and in each `package.json` file under the `renovate` object
--   Find and process all `package.json` files in each repository
--   Process `dependencies`, `devDependencies` and `optionalDependencies` in each `package.json`
--   Use separate branches/PR for each dependency
--   Use separate branches for each *major* version of each dependency
--   Pin dependencies to a single version, rather than use ranges
--   Update `yarn.lock` and/or `package-lock.json` files if found
--   Create Pull Requests immediately after branch creation
-
-## What If I Need To .. ?
+If you need a specific behaviour and it's not mentioned here - or it's more
+complicated - feel free to raise an
+[Issue](https://github.com/renovateapp/renovate/issues) - configuration
+questions are welcome in this repository.
 
 ### Run renovate on all repositories that the account has access to
 
-Set configuration option `autodiscover` to `true`, via CLI, environment, or configuration file. Obviously it's too late to set it in any `renovate.json` or `package.json`.
-
-### Use an alternative branch for Pull Request target
-
-If for example your repository default branch is `master` but your Pull Requests should target branch `next`, then you can configure this via the `baseBranch` configuration option. To do this, add this line to the `renovate.json` in the *default* branch (i.e. `master` in this example).
-
-```
-{
-  "baseBranch": "next"
-}
-```
+Set configuration option `autodiscover` to `true`, via CLI, environment, or
+configuration file. Obviously it's too late to set it in any `renovate.json` or
+`package.json`.
 
 ### Support private npm modules
 
-If you are running your own Renovate instance, then the easiest way to support private modules is to make sure the appropriate credentials are in `.npmrc` or `~/.npmrc`;
+If you are running your own Renovate instance, then the easiest way to support
+private modules is to make sure the appropriate credentials are in `.npmrc` or
+`~/.npmrc`;
 
-If you are using a hosted Renovate instance (such as the Renovate app), and your `package.json` includes private modules, then you can:
+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.
+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
 
-Renovate itself will run as often as its administrator has configured it (e.g. hourly, daily, etc). But you may wish to update certain repositories less often, or even specific packages at a different schedule.
-
-If you want to control the days of the week or times of day that renovate updates packages, use the `timezone` and `schedule` configuration options.
-
-By default, Renovate schedules will use the timezone of the machine that it's running on. This can be overridden in global config. Finally, it can be overridden on a per-repository basis too, e.g.:
-
-```
-  "timezone": "America/Los_Angeles",
-```
-
-The timezone must be one of the valid [IANA time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).
-
-Now that your timezone is set, you can define days of week or hours of the day in which renovate will make changes. For this we rely on text parsing of the library [later](http://bunkat.github.io/later/parsers.html#text) and its concepts of "days", "time_before", and "time_after".
-
-Example scheduling:
-
-```
-every weekend
-before 5:00am
-[after 10pm, before 5:00am]
-[after 10pm every weekday, before 5am every weekday]
-on friday and saturday
-```
-
-This scheduling feature can be particularly useful for "noisy" packages that are updated frequently, such as `aws-sdk`.
-
-To restrict `aws-sdk` to only weekly updates, you could add this package rule:
-
-```
-  "packageRules": [
-    {
-      "packageNames": ["aws-sdk"],
-      "schedule": ["after 9pm on sunday"]
-    }
-  ]
-```
-
-Note that schedule must be in the form of an array, even if only one schedule is present. Multiple entries in the array means "or".
-
-### Selectively enable or disable renovate for specific `package.json` files
-
-You could:
-
--   Add a `renovate.json` to the root of your repository and explicitly whitelist which `package.json` files you want renovated in the `packageFiles` configuration option, 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
-
-If you want to disable `renovate` for `optionalDependencies`, for example, you could define your own `depTypes` array (in either a `renovate.json` or `package.json` file)
-
-### Use a single branch/PR for all dependency upgrades
-
-Add a configuration for configuration option `groupName` set to value `"all"`, at the top level of your `renovate.json` or `package.json`.
-
-### Use separate branches per dependency, but not one per major release
-
-Set configuration option `separateMajorReleases` to `false`.
-
-### Keep using semver ranges, instead of pinning dependencies
-
-Set configuration option `pinVersions` to `false`.
-
-### Keep lock files (including sub-dependencies) up-to-date, even when `package.json` hasn't changed
-
-This is enabled by default, but its schedule is set to `['before 5am on monday']`. If you want it more frequently, then update the `schedule` field inside the `lockFileMaintenance` object.
-
-### Wait until tests have passed before creating the PR
-
-Set configuration option `prCreation` to `"status-success"`
-
-### Wait until tests have passed before creating a PR, but create the PR even if they fail
-
-Set configuration option `prCreation` to `"not-pending"`
-
-### Assign PRs to specific user(s)
-
-Set the configuration option `assignees` to an array of usernames.
-
-### Add labels to PRs
-
-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.
-
-e.g.
-
-```
-"packageRules": [
-  {
-    "packageNames": ["abc"],
-    "assignees": ["importantreviewer"]
-  }
-]
-```
-
-### Apply a rule, but only for packages starting with `abc`
-
-Do the same as above, but instead of using `packageNames`, use `packagePatterns` and a regex. e.g.
-
-```
-"packageRules": [
-  {
-    "packagePatterns": "^abc",
-    "assignees": ["importantreviewer"]
-  }
-]
-```
-
-### Group all packages starting with `abc` together in one PR
-
-As above, but apply a `groupName`, e.g.
-
-```
-"packageRules": [
-  {
-    "packagePatterns": "^abc",
-    "groupName": ["abc packages"]
-  }
-]
-```
-
-### Change the default branch name, commit message, PR title or PR description
-
-Set the `branchName`, `commitMessage`, `prTitle` or `prBody` configuration options:
-
-```
-"branchName": "vroom/{{depName}}-{{newVersionMajor}}.x",
-"commitMessage": "Vroom vroom dependency {{depName}} to version {{newVersion}}",
-"prTitle": "Vroom {{depName}},
-```
-
-### Automatically merge passing Pull Requests
-
-Set configuration option `autoMerge` to `minor` if you want this to apply only to minor upgrades, or set to value `all` if you want it applied to both minor and major upgrades.
-
-### Separate patch releases from minor releases
-
-Renovate's default behaviour is to separate major and minor releases, while patch releases are also consider "minor". For example if you were running `q@0.8.7` you would receive one branch for the minor update to `q@0.9.7` and a second for the major update to `q@1.4.1`.
-
-If you set the configuration option `separatePatchReleases` to `true`, or you configure `automerge` to have value `"patch"`, then Renovate will then separate patch releases as well. For example, if you did this when running `q@0.8.7` then you'd receive three PRs - for `q@0.8.13`, `q@0.9.7` and `q@1.4.1`.
-
-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
-
-The result of this would hopefully be that you barely notice Renovate during the week while still getting the benefits of patch updates.
-
-### Update Meteor package.js files
-
-Renovate supports Meteor's `package.js` files - specifically, the `Npm.depends` section. As with npm, it will not renovate any `http*` URLs, but will keep all semantic versions up to date. (e.g. update version `1.1.0` to `1.1.1`)
-
-Meteor support is opt-in, meaning Renvoate won't attempt to search for Meteor files by default. To enable it, add `":meteor"` to your Renovate config `extends` array.
-
-e.g. if your renovate.json looks like:
-
-```json
-{
-  "extends": [":library"]
-}
-```
-
-Then update it to be:
-
-```json
-{
-  "extends": [":library", ":meteor"]
-}
-```
-
-Once you've done this, Renovate will:
-
-- Search the repository for all `package.js` files which include `Npm.depends`
-- Check the npm registry for newer versinos for each detected dependency
-- Patch the `package.js` file if updates are found and create an associated branch/PR
-
-If you wish to combine upgrades into one PR or any other similar configuration, you can do this just like with `package.json` dependencies by adding configuration or presets to your `renovate.json` file.
-
-### Update Dockerfile FROM dependencies
-
-Renovate supports updating `FROM` instructions in `Dockerfile`s.
-
-Dockerfile support is opt-in, meaning Renvoate won't attempt to search for Dockerfiles by default. To enable it, add `":docker"` to your Renovate config `extends` array.
-
-e.g. if your renovate.json looks like:
-
-```json
-{
-  "extends": [":library"]
-}
-```
-
-Then update it to be:
-
-```json
-{
-  "extends": [":library", ":docker"]
-}
-```
-
-Once you've done this, Renovate will:
-
-- Search the repository for all `Dockerfile` files that have `FROM x` as the first non-comment line
-- If x includes a digest, Renovate will check the Docker registry to see if a newer digest is available for the same tag and patch the Dockerfile
-- If x does not include a digest, Renovate will look up the current digest for this image/tag and add it to the Dockerfile
+Renovate itself will run as often as its administrator has configured it (e.g.
+hourly, daily, etc). But you may wish to update certain repositories less often,
+or even specific packages at a different schedule.
 
-If you wish to combine upgrades into one PR or any other similar configuration, you can do this just like with `package.json` dependencies by adding configuration or presets to your `renovate.json` file.
+If you want to control the days of the week or times of day that renovate
+updates packages, use the `timezone` and `schedule` configuration options.

docs/local-development.md

+# Local Development
+
+This document serves to give tips and tricks on how to run Renovate locally to add features or fix bugs.
+Please submit PRs to improve it if you think anything is unclear or you can think of something that should be added.
+
+## Install
+
+#### Fork and Clone
+
+If you will contribute to the project, you should first "fork" it using the GitHub Website and then clone your fork.
+
+#### Node version
+
+Renovate supports node.js versions 8 and above. Use a version manager like `nvm` or `n` if you'll need to switch between versions easily.
+
+#### Install dependencies
+
+We use [yarn](https://github.com/yarnpkg/yarn) so run `yarn install` to install dependencies instead of `npm install`.
+
+#### Verify installation
+
+Run `yarn start`. You should see this error:
+
+```
+FATAL: Renovate fatal error: You need to supply a GitHub token.
+```
+
+## Platform Account Setup
+
+Although it's possible to make small changes without testing against a real repository, in most cases it's important that you run a "real" test on a repository before you submit a feature or fix.
+It's possible to do this against GitHub or GitLab public hosts, and you can also use both.
+
+#### Register new account (optional)
+
+It's recommended that you set up a dedicated test account on GitHub or GitLab, so that you minimise the risk that you accidentally cause problems when testing out Renovate.
+e.g. if your GitHub username is "alex88" then maybe you register "alex88-testing" for use with Renovate.
+
+#### Generate platform token
+
+Once you have decided on your platform and account, log in and generate a "Personal Access Token" that can be used to authenticate Renovate.
+
+#### Export platform token
+
+Although you can specify a token to Renovate using `--token=`, it is annoying if you need to include this every time.
+You are better off to instead export an Environment Variable for this.
+If your platform of choice is GitHub, then export GITHUB_TOKEN, and if it's GitLab then export GITLAB_TOKEN.
+It's also find to export both so that you can switch between platforms.
+
+## Tests
+
+You can run `yarn test` locally to test your code. We test all PRs using the same tests, run on TravisCI. `yarn test` runs an `eslint` check, a `prettier check`, and then all the unit tests using `jest`.
+
+## Jest
+
+You can run just the Jest unit tests by running `yarn jest`. You can also run just a subset of the Jest tests using file matching, e.g. `yarn jest lock-files` or `yarn jest workers/branch`. If you get a test failure due to a "snapshot" mismatch, and you are sure that you need to update the snapshot, then you can append `-u` to the end. e.g. `yarn jest lock-files -u` would update the saved Snapshots for _all_ tests in `test/workers/branch/lock-files.spec.js`.
+
+#### Coverage
+
+The Renovate project maintains 100% test coverage, so any Pull Request will fail if it does not contain full coverage for code.
+Using `// instanbul ignore` is not ideal but sometimes is a pragmatic solution if an additional test wouldn't really prove anything.
+
+To view the current test coverage locally, open up `coverage/lcov-report/index.html` in your browser.
+
+Do not let coverage put you off submitting a PR! Maybe we can help, or at least guide.
+Also, it can be good to submit your PR as a work in progress (WIP) without tests first so that you can get a thumbs up from others about the changes, and write tests after.
+
+#### Linting and formatting
+
+We use [Prettier](https://github.com/prettier/prettier) for code formatting. If
+your code fails `yarn test` due to a `prettier` rule then you should find that the offending file will be updated automatically and pass the second time you run `yarn test` because each time you run it, it includes the `--fix` command automatically. You usually shouldn't need to fix any prettier errors manually.
+
+## Tips and tricks
+
+#### Forked repositories
+
+Quite often, the quickest way for you to test or fix something is to fork an existing repository.
+However, by default Renovate skips over repositories that are forked.
+To override this default, you need to specify the setting `renovateFork` as `true`.
+
+Option 1: Add `"renovateFork": true` to the `renovate.json` of the repository
+Option 2: Run Renovate with the CLI flag `--renovate-fork=true`
+
+#### Log files
+
+Usually, `debug` is good enough to troubleshoot most problems or verify functionality.
+
+When logging at debug, it's usually easiest to view the logs in a text editor, so in that case you can run like this:
+
+```
+$ rm -f debug.log && yarn start myaccount/therepo --log-level=debug > debug.log
+```
+
+The above will delete any existing `debug.log` and then save Renovate's output to that file.
+
+#### Adding configuration options
+
+We wish to keep backwards-compatibility as often as possible, as well as make
+the code configurable, so most new functionality should be controllable via
+configuration options.
+
+If you wish to add one, add it to `lib/config/definitions.js` and then add documentation to `website/docs/_posts/2017-10-05-configuration-options.md`.