This PR implements eslint-inspired shareable configs. With this feature, we:
- Add new config option "extends"
* This is an array of preset config names that the current config or preset extends/inherits from
- Add new config option "description"
* Each preset config should include a description of its functionality that is human-readable
- Provide a set of commonly use configs called "preset defaults"
- Provide two "full" preset configs: "app" and "library"
* Almost the same but app pins *all* version numbers while library only pins devdependencies
- Replace regular config in onboarding with one of these two presets
- Generate human-readable description of config in Onboarding PR
- Support npm for hosting configs (both scoped and non-scoped)
Closes#657, Closes#671, Closes#647
It was a mistake to enable this feature by default, and should be disabled. A check has been made to set the status to “success” if it was previously “pending” and the setting is now false. This should also cover the case when someone enables it and then disables it.
Fixes#667
Repository initialisation is refactored so that all package files and their content is retrieved up-front before an renovating begins. This allows us to know both how many package files as well as determine if there is renovate json in a package.json before triggering the onboarding PR.
Closes#634
Renovate now adds a status check renovate/unpublish-safe that has the following behaviour:
If any upgrade in the branch is < 24 hours old then the status check state is "pending"
If all upgrades in the branch are 24 hours or more old then the status check state is "success"
This is able to be disabled via a new option "unpublishSafe".
Closes#494
No need for {{semanticPrefix}} to be specified in templates now - it will be implicitly added to start of commit message and PR titles if semanticCommits=true
depTypes configuration is now refactored from being an array of strings/objects to having each type of dep (`dependencies`, `devDependencies`, `optionalDependencies`, `peerDependencies`) be a first class object in the namespace. The "old" way of configuring is still supported but is transformed using a migrateConfig script. Later, PRs will be raised to impacted repositories to suggest the new config.
This PR adds explicit patch support. A user can set `separatePatchReleases` to true and receive not only major/minor updates but also patch updates separately. This functionality is also implicitly enabled if `automerge` is set to `patch`.
This PR also enables separate major/minor/patch configuration, e.g. config overrides for major versions, for patch versions, etc. `branchName` is currently overridden for patch branches using this technique.
Closes#390, Closes#538