renovatebot · kvanzuijlen · Dec 28, 2023 · Dec 28, 2023 · Dec 28, 2023 · Dec 28, 2023
diff --git a/docs/development/adding-a-package-manager.md b/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)
 

diff --git a/docs/development/best-practices.md b/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:

diff --git a/docs/development/configuration.md b/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.

diff --git a/docs/development/design-decisions.md b/docs/development/design-decisions.md
@@ -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
diff --git a/docs/development/help-us-help-you.md b/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.
diff --git a/docs/development/issue-labeling.md b/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.
 

diff --git a/docs/development/local-development.md b/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
@@ -100,7 +100,8 @@ To ensure everything is working properly on your end, you must:
 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`
 
-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.
+Don't worry about the token error for now.
+You'll configure the token properly a little later, so keep reading.
 
 You only need to do these steps once.
 
@@ -132,9 +133,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 +152,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
@@ -227,14 +228,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
diff --git a/docs/development/minimal-reproductions.md b/docs/development/minimal-reproductions.md
@@ -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

diff --git a/docs/development/remote-development.md b/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
 

diff --git a/docs/development/triage-guide.md b/docs/development/triage-guide.md
@@ -13,7 +13,7 @@ The general triage workflow is similar for bug reports and feature requests, but
 Take the following steps on an incoming bug report:
 
 1. Determine if this is a valid bug report at all, close and optionally delete obvious spam.
-1. If poster is asking a configuration question, or has not made a convincing case that it's really a bug, then convert to a "Ask a question" discussion, add either a response or at least a note that it's been converted.
+1. If poster is asking a configuration question, or has not made a convincing case that it's really a bug, then convert to an "Ask a question" discussion, add either a response or at least a note that it's been converted.
 1. Determine if this is a duplicate of an open issue/discussion, if duplicate: link to earlier issue/discussion, apply `duplicate` label and close the issue/discussion.
 1. Check what version of Renovate is used, if not on current major version: apply the `auto:retry-latest` label. This makes a bot comment to try again with a newer version of Renovate.
 1. Check if the _relevant_ logs are provided. If not apply the `auto:logs` label.
@@ -23,7 +23,7 @@ Take the following steps on an incoming bug report:
 Take the following steps on an incoming feature request:
 
 1. Determine if this is a valid feature request at all, close and optionally delete obvious spam.
-1. If poster is asking a configuration question, or has not made a convincing case that it's really a feature request, then convert to a "Ask a question" discussion, add either a response or at least a note that it's been converted.
+1. If poster is asking a configuration question, or has not made a convincing case that it's really a feature request, then convert to an "Ask a question" discussion, add either a response or at least a note that it's been converted.
 1. Determine if this is a duplicate of an open issue, if duplicate: link to earlier issue/discussion, apply `duplicate` label and close the issue/discussion.
 1. Check what version of Renovate is used, if not on current major version: apply the `auto:retry-latest` label. This makes a bot comment to try again with a newer version of Renovate.
 1. Make a best-effort judgement if this is a reasonable feature to put into Renovate. If in doubt, let the core maintainers decide.
@@ -40,7 +40,7 @@ In short: users create discussions, and when it's clear what we need to do, the
 
 ## What a triagist is allowed to do
 
-If you've been given triage rights, you are allowed to do the following things:
+If you've been given triage rights, you're allowed to do the following things:
 
 - Apply labels to issues/discussions
 - Close, reopen, and assign all issues and pull requests
@@ -116,7 +116,7 @@ Ideally warn the user with an `auto:bad-vibes` label first, and then use the `au
 
 ### Going from `status:requirements` to actionable issue
 
-One of the most important non-code contributions people can do is help features and fixes go from `status:requirements` to a actionable issue.
+One of the most important non-code contributions people can do is help features and fixes go from `status:requirements` to an actionable issue.
 We use the label `status:requirements` to mean "more information or research is needed before someone could start coding this".
 
 It can sometimes be an oversight of the maintainers, but more often it's because there are requirements or edge cases to consider and the user hasn't got an opinion or time to think about them and contribute enough.

diff --git a/docs/development/zod.md b/docs/development/zod.md
@@ -100,7 +100,7 @@ const Box = z.object({
     red: z.number(),
     green: z.number(),
     blue: z.number(),
-  })
+  }),
   weight: z.number(),
 });
 

diff --git a/docs/usage/bazel.md b/docs/usage/bazel.md
@@ -20,13 +20,13 @@ Renovate upgrades dependencies in Bazel `WORKSPACE` files and `MODULE.bazel` fil
 
 Renovate searches [Bazel registries](https://bazel.build/external/registry) to find new Bazel module versions.
 You customize the registries your Bazel workspace uses by including [`--registry`](https://bazel.build/reference/command-line-reference#flag--registry) entries in your [`.bazelrc` files](https://bazel.build/run/bazelrc).
-Renovate checks the workspace's `.bazelrc` files for custom registry entries.
+Renovate checks the `.bazelrc` files within the workspace for custom registry entries.
 If no registries are found, Renovate defaults to the [Bazel Central Registry](https://bcr.bazel.build/).
 
 Here are some important points about Renovate's Bazel registry searches.
 Renovate:
 
-- uses _all_ `--registry` values found in a workspace's `.bazelrc` file
+- uses _all_ `--registry` values found in the `.bazelrc` file within the workspace
 - uses any files that are transitively imported by a `.bazelrc` file
 - only uses `--registry` values that are not associated with [a configuration](https://bazel.build/run/bazelrc#config)
 - queries the registries in the order that they are found in the `.bazelrc` file

diff --git a/docs/usage/bot-comparison.md b/docs/usage/bot-comparison.md
@@ -153,7 +153,7 @@ You can self-host Dependabot on other platforms than GitHub but none are officia
 If you want to customize Dependabot, or self-host on another platform, you can use [`dependabot-core`](https://github.com/dependabot/dependabot-core).
 Quote from the `dependabot-core` readme:
 
-> It [`dependabot-core`] currently supports opening Pull Requests against repositories hosted on GitHub, Github Enterprise, Azure DevOps, GitLab, BitBucket, and AWS CodeCommit.
+> It [`dependabot-core`] currently supports opening Pull Requests against repositories hosted on GitHub, GitHub Enterprise, Azure DevOps, GitLab, BitBucket, and AWS CodeCommit.
 
 #### `dependabot-script`