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.
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.
Configuration options applied per-package override those applied per package-type, which override those per-repository, which override those which are global (all repositories).
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).
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.
`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).
- 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
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.
`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?
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.
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.