docs: update development docs

docs/development/adding-a-package-manager.md

@@ -5,7 +5,7 @@ This document describes the steps to take if you are interested in adding new la
 ### Background
 
 Renovate began life as a JavaScript-only, specifically for the npmjs ecosystem.
-Over time, additional "package managers" (e.g. Meteor.js, Dockerfile, nvm) have been added and the codebase incrementally refactored and improved with many of those to make it easier to add newer ones in future.
+Over time, additional "package managers" (e.g. Pip, Dockerfile, nvm) have been added and the codebase incrementally refactored and improved with many of those to make it easier to add newer ones in future.
 
 ### Code structure
 

docs/development/branches-commits.md

@@ -12,16 +12,4 @@ A positive side effect of this is that it allows us to have a shortcut rule of,
 
 ## 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 Requests 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.
-
-#### Azure DevOps
-
-Azure DevOps is implemented similarly to GitLab.
+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 by force pushing with `git` to the existing branch.

docs/development/configuration.md

@@ -10,14 +10,12 @@ Configuration is supported via any or all of the below:
 - `renovate.json`, `renovate.json5`, `.github/renovate.json`, `.github/renovate.json5`, `.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
-overrides the config file, which overrides defaults.
+The above are listed in **_reverse order_** of preference. e.g. CLI values will override environment values if they conflict.
 
 ### Default Configuration
 
 Default configuration values can be found in
-[lib/config/definitions.js](../lib/config/definitions.js)
+[lib/config/definitions.ts](../../lib/config/definitions.ts)
 
 ### Configuration File
 
@@ -50,9 +48,7 @@ To configure any `<list>` items, separate with commas. E.g. `renovate --labels=r
 
 ### renovate.json
 
-If you add a `renovate.json` file to the root of your repository, you can use
-this to override default settings. `renovate` will still auto-discover all `package.json` files in the
-repository.
+If you add a `renovate.json` file to the root of your repository, you can use this to override default settings.
 
 ### package.json
 
@@ -72,4 +68,4 @@ any other settings above.
 
 Please see [https://docs.renovatebot.com/configuration-options/](https://docs.renovatebot.com/configuration-options/) for a list of user-facing configuration options.
 
-For further options when running your own instance of Renovate, please see the full config definitions file at `lib/config/definitions.js`.
+For further options when running your own instance of Renovate, please see the full config definitions file at `lib/config/definitions.ts`.

docs/development/deployment.md

-# Deployment
-
-Before deploying the script for scheduled runs, it's recommended you test your
-settings locally first.
-
-## Server cron
-
-Adding `renovate` as a `cron` job is the simplest way to deploy.
-
-### Installation
-
-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.
-
-Running daily should suit most people. At most, hourly.

docs/development/design-decisions.md

@@ -2,7 +2,7 @@
 
 This file documents the design choices as well as configuration options.
 
-#### Stateless
+## Stateless
 
 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
@@ -10,41 +10,22 @@ 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.
-
 ## Synchronous Operation
 
-The script current processes repositories, package files, and dependencies
-within them all synchronously.
+The script current processes repositories and branches within them all synchronously.
 
 - Greatly reduces the 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`.
-
 ## Cascading Configuration
 
 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
+## Automatic discovery of package file locations
 
-The 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 `includePaths`,
-where you list the file paths manually (e.g. limit to just `package.json` in the root of the repository).
+The default behaviour is to auto-discover all package file (e.g. `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 `includePaths`, where you list the file paths manually (e.g. limit to just `package.json` in the root of the repository).
 
 ## Separate Branches per dependency
 
@@ -66,23 +47,18 @@ are available. For example, if the current example is 1.6.0 and upgrades to 1.7.
 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 overridden via the config option `separateMajorMinor`.
 
 ## 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
+- 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.
 

docs/development/local-development.md

@@ -159,7 +159,7 @@ 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/configuration-options.md`.
+If you wish to add one, add it to `lib/config/definitions.ts` and then add documentation to `website/docs/configuration-options.md`.
 
 ## Debugging
 

docs/development/pre-release.md

-# Pre-release features
-
-We try to only turn on features by default once we think they are well-tested and unlikely to cause anyone _problems_. Sometimes it's fine to enable a feature by default even if it's not "complete" so long as the functionality that does exist is reliable and useful as-is.
-
-The below is a list of upcoming features with statuses, as well as info on how you can help test them.
-
-As a general guide:
-
-- Alpha: in need of additional testing
-- Beta: almost ready for default enabling for everyone, but ideally needs a few more users running it in production giving it the thumbs-up
-- Generally Available (GA): safe to enable by default for everyone
-
-### Bitbucket Cloud
-
-Status: beta
-
-Bitbucket Cloud support (i.e. [https://bitbucket.org](https://bitbucket.org)) is still missing some nice-to-have features (issues, etc) but none of these have to hold it back from being considered GA. Mostly, we'd just like to get some more feedback from users who have been testing it.
-
-Note: we plan to add support for Bitbucket.org to the _hosted_ Renovate Bot _service_ that already supports GitHub.com and GitLab.com, so you won't need to run your own bot unless you want to.
-
-How to use: run your own bot from npm, Docker or clone the repository. Follow the instructions from: [https://github.com/renovatebot/renovate/blob/master/docs/self-hosting.md#bitbucket-cloud](https://github.com/renovatebot/renovate/blob/master/docs/self-hosting.md#bitbucket-cloud).
-
-### Bundler
-
-Status: alpha
-
-Bundler support is considered "alpha" because there's currently a PR underway to replace the initial JS-based parsing with a Ruby-based one. Perhaps your `Gemfile` works already though, in which case you can test out the other features.
-
-How to use: Add `"bundler": { "enabled": true }` to either your bot config or your repository's `renovate.json`. If your repository contains _only_ Bundler package files and no others then you'll need to add the `renovate.json` manually as otherwise Renovate won't detect any package files by default and will skip the Onboarding PR.
-
-### Gradle
-
-Status: beta
-
-Gradle support has been implemented but is undergoing a rewrite so that it relies less on third-party Gradle plugins and can take more control itself of things like stable/unstable and major/minor.
-
-How to use: Add `"gradle": { "enabled": true }` to either your bot config or your repository's `renovate.json`. If your repository contains _only_ Gradle package files and no others then you'll need to add the `renovate.json` manually as otherwise Renovate won't detect any package files by default and will skip the Onboarding PR.
-
-### Maven
-
-Status: beta
-
-Maven support has been implemented, initially supporting exact/pinned versions only, which should still be useful for the majority of users who don't specify ranges in their `pom.xml` files.
-
-How to use: Add `"maven": { "enabled": true }` to either your bot config or your repository's `renovate.json`. If your repository contains _only_ Maven package files and no others then you'll need to add the `renovate.json` manually as otherwise Renovate won't detect any package files by default and will skip the Onboarding PR.
-
-### Pipenv
-
-Status: beta
-
-Pipenv support has been implemented awaits a bit more testing before being switched on by default.
-
-How to use: Add `"pipenv": { "enabled": true }` to either your bot config or your repository's `renovate.json`. If your repository contains _only_ Pipenv package files and no others then you'll need to add the `renovate.json` manually as otherwise Renovate won't detect any package files by default and will skip the Onboarding PR.

docs/development/readme.md

@@ -2,4 +2,4 @@
 
 This directory is intended to provide documentation for developers/contributors on the Renovate project. For user-facing documentation - e.g. for how to configure Renovate as a user - please see https://docs.renovatebot.com
 
-If you would like to contribute to Renovate or get it running locally for some other reason, please check out [contributing.md](../.github/contributing.md) for steps on how to set up the project locally.
+If you would like to contribute to Renovate or get it running locally for some other reason, please check out [contributing.md](../../.github/contributing.md) for steps on how to set up the project locally.