docs: Proofreading + general improvements

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

@@ -42,7 +42,7 @@ It takes as arguments the file's content and optionally the file's full file pat
 The function returns an array of detected or extracted dependencies, including the:
 
 - dependency name
-- dependency type (dependencies, devDependencies, etc)
+- dependency type (dependencies, devDependencies, etc.)
 - currentValue
 - versioning used (like SemVer, PEP 440)
 

docs/development/best-practices.md

@@ -158,11 +158,11 @@ For `WARN`, `ERROR` and `FATAL log messages use logger metadata.
 Also use logger metadata the result is a complex metadata object needing a multiple-line pretty stringification.
 
 For `INFO` log messages inline the metadata into the log message.
-Also inline the metadata if the metadata object is complex.
+Also, inline the metadata if the metadata object is complex.
 
 `WARN`, `ERROR` and `FATAL` messages are often used in metrics or error catching services.
 These log messages should have a consistent `msg` component, so they can be automatically grouped or associated.
-Metadata that's seperate from its message is hard for humans to read.
+Metadata that's separate from its message is hard for humans to read.
 Try to combine the metadata into the message, unless it's too complex to do so.
 
 Good:

docs/development/branches-commits.md

@@ -25,5 +25,5 @@ This means we let Renovate force-push a single new commit whenever it needs to.
 For example:
 
 1. Renovate creates a `renovate/jest` branch to update the Jest package to `1.0.1`
-1. Renovate later finds a newer `1.1.0` version
-1. Renovate force-pushes a new commit for the `1.1.0` update into its `renovate/jest` branch
+2. Renovate later finds a newer `1.1.0` version
+3. Renovate force-pushes a new commit for the `1.1.0` update into its `renovate/jest` branch

docs/development/configuration.md

@@ -24,7 +24,7 @@ If you need an alternate location or name, set it in the environment variable `R
 For example `RENOVATE_CONFIG_FILE=myconfig.js` or `RENOVATE_CONFIG_FILE=myconfig.json` and not `RENOVATE_CONFIG_FILE=myconfig`.
 If none is provided, or the file type is invalid, Renovate will fail.
 
-If you are in an ESM repo (`"type": "module"` in `package.json`) then you must use a `.cjs` extension and set `RENOVATE_CONFIG_FILE`.
+If you're in an ESM repo (`"type": "module"` in `package.json`) then you must use a `.cjs` extension and set `RENOVATE_CONFIG_FILE`.
 For example `RENOVATE_CONFIG_FILE=myconfig.cjs`.
 
 Using a configuration file gives you very granular configuration options.

docs/development/creating-editing-renovate-presets.md

@@ -8,7 +8,7 @@ Follow the rules below to increase the chance that your pull request gets merged
 ## General rules
 
 1. Avoid creating presets for problems which can be fixed upstream
-1. The internal preset should be helpful for a significant number of Renovate users
+2. The internal preset should be helpful for a significant number of Renovate users
 
 ### Specific rules
 
@@ -27,20 +27,20 @@ We have multiple kinds of `group:` presets, with different rules.
 ##### Rules for `group:*` presets
 
 1. Finally, any other `group:*` presets can be added if they are beneficial to a wide number of users
-1. They don't need to be added to `group:recommended`, meaning that users will "opt in" to them one by one and not get them automatically from `config:recommended`, which includes `group:monorepo` and `group:recommended`
+2. They don't need to be added to `group:recommended`, meaning that users will "opt in" to them one by one and not get them automatically from `config:recommended`, which includes `group:monorepo` and `group:recommended`
 
 #### Replacement presets
 
 Rules:
 
 1. Replacement PRs should ideally propose a replacement only once the user is on a compatible version, by specifying a compatible `matchCurrentVersion` constraint
-1. If no compatible replacement upgrade is possible, it's acceptable to propose an incompatible one (e.g. a major version upgrade)
-1. Replacements should update the user to the first recommended version of the new dependency and not include any new changes - whether breaking or not - if they can be avoided
+2. If no compatible replacement upgrade is possible, it's acceptable to propose an incompatible one (e.g. a major version upgrade)
+3. Replacements should update the user to the first recommended version of the new dependency and not include any new changes - whether breaking or not - if they can be avoided
 
 #### Monorepo presets
 
 Rules:
 
 1. The primary use case of monorepo presets is finding packages from the same origin source repository which should be updated together
-1. Packages from the same repository which are developed and versioned independently do not need to be grouped as a monorepo, but in many cases we still do
-1. Packages from separate repositories but which are released together and dependent on each other may also be added to the "monorepo" definitions even if not strictly true
+2. Packages from the same repository which are developed and versioned independently do not need to be grouped as a monorepo, but in many cases we still do
+3. Packages from separate repositories but which are released together and dependent on each other may also be added to the "monorepo" definitions even if not strictly true

docs/development/design-decisions.md

@@ -32,10 +32,10 @@ This means that specific configuration options always override more general conf
 From most specific to least specific:
 
 1. Update type (e.g. `major`, `minor`, `patch`)
-1. Package (e.g. `lodash`, `django`)
-1. Manager (e.g. `npm`, `pypi`)
-1. Repository config
-1. Global configuration
+2. Package (e.g. `lodash`, `django`)
+3. Manager (e.g. `npm`, `pypi`)
+4. Repository config
+5. Global configuration
 
 ## Automatic discovery of package file locations
 
@@ -49,7 +49,7 @@ You could limit Renovate to only update the `package.json` in the root of the re
 
 By default, `renovate` will maintain separate branches for each dependency.
 So if 20 dependencies need updating, there will be at least 20 branches/PRs.
-Although this may seem undesirable, it's even less desirable if all 20 were in the same Pull Request and it's very difficult to work out which upgrade caused the test failure.
+Although this may seem undesirable, it's even less desirable if all 20 were in the same Pull Request, and it's very difficult to work out which upgrade caused the test failure.
 
 But you can override the default templates for branch name to get 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.
@@ -83,7 +83,7 @@ Note: You can configure the branch names by using the string template `branchNam
 By default, the script does not create a new PR if it finds a previously-closed PR with the same branch name and PR title (assuming the PR title has a version in it).
 This allows users to close unwelcome upgrade PRs and not worry about them being recreated every run.
 
-## Rebasing Unmergeable Pull Requests
+## Rebasing unmergeable Pull Requests
 
 With the default behavior of one branch per dependency, it's often the case that a PR gets merge conflicts after an adjacent dependency update is merged.
 On most platforms you can use a web interface to resolve merge conflicts, but you're still resolving the conflicts manually, which is annoying.
@@ -107,6 +107,6 @@ Alternatively, consider using a Configuration File.
 
 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
+- `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/development/help-us-help-you.md

@@ -6,7 +6,7 @@ Please follow these points whenever interacting in this repo.
 ## Be positive and polite
 
 This project is open source, and has the work of a lot of contributors who are proud of it.
-Please avoid unnecessary criticism, especially if you are new to the project or have not contributed anything.
+Please avoid unnecessary criticism, especially if you're new to the project or have not contributed anything.
 You are welcome to make it better, and do not need to criticize the works of others first.
 
 ## Be considerate of the time of people helping you
@@ -77,5 +77,5 @@ Don't raise a bug report unless it's definitely a bug.
 "I don't like this" or "I didn't expect this to happen" is not the same thing as a bug.
 
 Many unjustified bug reports are filed because people they think it will get them more attention.
-Instead, you may be wasting maintainer time because we have to reclassify your invalid bug report or convert it to a discussion, and you are much less likely to get the attention you're hoping for.
+Instead, you may be wasting maintainer time because we have to reclassify your invalid bug report or convert it to a discussion, and you're much less likely to get the attention you're hoping for.
 If in doubt, start a discussion instead.

docs/development/issue-labeling.md

@@ -185,7 +185,7 @@ Add a label `duplicate` to issues/PRs that are a duplicate of an earlier issue/P
 Add a label `good first issue` to issues that are small, easy to fix, and do-able for a newcomer.
 This label is sometimes picked up by tools or websites that try to encourage people to contribute to open source.
 
-Add the label `help wanted` to indicate that we need the original poster or someone else to do some work or it is unlikely to get done.
+Add the label `help wanted` to indicate that we need the original poster or someone else to do some work, or it is unlikely to get done.
 
 Add a label `auto:bad-vibes` to any discussion containing rude comments such as excessive criticism or ungratefulness.
 
@@ -198,8 +198,8 @@ Add a label `auto:format-code` to any Discussion which needs code formatting.
 Add a label `auto:logs` to indicate that there's a problem with the logs, and the contributor needs to do one of these things:
 
 1. Provide logs (if there are none yet)
-1. Provide more logs (in case current logs are insufficient)
-1. Format their logs properly
+2. Provide more logs (in case current logs are insufficient)
+3. Format their logs properly
 
 Add a label `auto:needs-details` to discussions which need more details to move forward.
 

docs/development/local-development.md

@@ -52,7 +52,7 @@ If you already installed a part, skip the corresponding step.
 
 #### VS Code Dev Containers
 
-If you are using [VS Code](https://code.visualstudio.com/) you can skip installing [the prerequisites](#prerequisites) and work in a [development container](https://code.visualstudio.com/docs/devcontainers/containers) instead.
+If you're using [VS Code](https://code.visualstudio.com/) you can skip installing [the prerequisites](#prerequisites) and work in a [development container](https://code.visualstudio.com/docs/devcontainers/containers) instead.
 
 - Install the [Dev Containers extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) and [check its system requirements](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers#system-requirements)
 - Open the repository folder in VS Code
@@ -96,18 +96,18 @@ The Renovate project uses the [pnpm](https://github.com/pnpm/pnpm) package manag
 To ensure everything is working properly on your end, you must:
 
 1. Install all dependencies with `pnpm install`
-1. Make a build with `pnpm build`, which should pass with no errors
-1. Verify all tests pass and have 100% test coverage, by running `pnpm test`
-1. Verify the installation by running `pnpm start`. You must see this error: `You must configure a GitHub personal access token`
+2. Make a build with `pnpm build`, which should pass with no errors
+3. Verify all tests pass and have 100% test coverage, by running `pnpm test`
+4. Verify the installation by running `pnpm start`. You must see this error: `You must configure a GitHub personal access token`
 
-Do not worry about the token error for now, as you will be given instructions on how to configure the token a little later down in this document.
+Do not worry about the token error for now, as you'll be given instructions on how to configure the token a little later down in this document.
 
 You only need to do these steps once.
 
 Before you submit a pull request you should:
 
 1. Install newer dependencies with `pnpm install`
-1. Run the tests with `pnpm test`
+2. Run the tests with `pnpm test`
 
 ## Platform Account Setup
 
@@ -132,9 +132,9 @@ You are better off to instead export the Environment Variable `RENOVATE_TOKEN` f
 
 ### Run against a real repo
 
-To make sure everything is working, create a test repo in your account, e.g. like `https://github.com/r4harry/testrepo1`.
+To make sure everything is working, create a test repo in your account, e.g. like `https://github.com/<account>/testrepo1`.
 Now, add a file called `.nvmrc` with the content `8.13.0`.
-Now run against the test repo you created, e.g. `pnpm start r4harry/testrepo1`.
+Now run against the test repo you created, e.g. `pnpm start <account>/testrepo1`.
 If your token is set up correctly, you should find that Renovate created a "Configure Renovate" PR in the `testrepo1`.
 
 If this is working then in future you can create other test repos to verify your code changes against.
@@ -151,7 +151,7 @@ Refactor PRs should ideally not change or remove tests (adding tests is OK).
 
 Run the Jest unit tests with the `pnpm jest` command.
 You can also run a subset of the Jest tests using file matching, e.g. `pnpm jest composer` or `pnpm jest workers/repository/update/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.
+If you get a test failure due to a "snapshot" mismatch, and you're sure that you need to update the snapshot, then you can append `-u` to the end.
 e.g. `pnpm jest composer -u` would update the saved snapshots for _all_ tests in `**/composer/**`.
 
 ### Coverage
@@ -215,9 +215,9 @@ You can debug Renovate with Chrome's inspect tool.
 Here's an example:
 
 1. Open `chrome://inspect` in Chrome, then select "Open dedicated DevTools for Node"
-1. Add a `debugger;` statement somewhere in the source code where you want to start debugging
-1. Run Renovate using `pnpm debug ...` instead of `pnpm start ...`
-1. Select "Resume script execution" in Chrome DevTools and wait for your break point to be triggered
+2. Add a `debugger;` statement somewhere in the source code where you want to start debugging
+3. Run Renovate using `pnpm debug ...` instead of `pnpm start ...`
+4. Select "Resume script execution" in Chrome DevTools and wait for your break point to be triggered
 
 ### VS Code
 
@@ -227,14 +227,12 @@ Here's an example:
 1. In the configuration file, e.g. `config.js` in the root directory of the project, add `token` with your Personal Access Token
 2. In the same configuration file, add `repositories` with the repository you want to test against. The file `config.js` would look something like this:
 
-```javascript
-module.exports = {
-  token: 'xxxxxxxx',
-  repositories: ['r4harry/testrepo1'],
-};
-```
-
-<!-- markdownlint-disable MD029 -->
+   ```javascript
+   module.exports = {
+     token: 'xxxxxxxx',
+     repositories: ['r4harry/testrepo1'],
+   };
+   ```
 
 3. Set a breakpoint somewhere in the source code and launch the application in debug mode with selected configuration as `debug`
 4. Wait for your breakpoint to be triggered

docs/development/minimal-reproductions.md

@@ -45,12 +45,12 @@ There are two ways to create a minimal reproduction:
 General steps:
 
 1. Create your minimal reproduction repository on GitHub, only use GitLab or Bitbucket if really needed
-1. Use the fewest number of repository files and dependencies
-1. Reduce the Renovate config to a minimum
-1. Remove private or secret information
-1. Create a `readme.md` file that explains the current behavior and expected behavior
-1. Set the repository visibility to `public`
-1. Give us the link to the repository
+2. Use the fewest number of repository files and dependencies
+3. Reduce the Renovate config to a minimum
+4. Remove private or secret information
+5. Create a `readme.md` file that explains the current behavior and expected behavior
+6. Set the repository visibility to `public`
+7. Give us the link to the repository
 
 ### Why we won't use your production repository to debug
 
@@ -85,11 +85,11 @@ After a while, issues without a reproduction may be closed unfixed.
 ### "I already described what you need in the issue"
 
 Thank you for describing your issue in detail.
-But we still need a minimal reproduction in a repository, and we'd like you to be the one to make sure it matches both your description as well as expected behavior.
+But we still need a minimal reproduction in a repository, and we'd like you to be the one to make sure it matches both your description and expected behavior.
 
 ### Forcing Renovate to create a lot of pending updates
 
-Put a old version of a frequently updated dependency in your repository.
+Put an old version of a frequently updated dependency in your repository.
 Set a high `minimumReleaseAge` for that dependency, for example:
 
 ```json

docs/development/remote-development.md

@@ -29,7 +29,7 @@ You'll use the same code editor and have the same config as all other developers
 
 - Waiting for the remote container to start
 - If your internet is down you can't work
-- If Codespaces is down you can't work
+- If GitHub Codespaces is down you can't work
 
 ## GitHub Codespaces