Revert "fix(deps): update dependency yargs to v17" (#2534)

Reverts #1912, fixes #2533

This reverts commit f419080fbf.

.github/ISSUE_TEMPLATE/01_bug_report.md

@@ -1,21 +0,0 @@
----
-name: Bug report
-about: Something not working as expected
-
----
-
-## Current behavior
-
-<!-- Describe how the issue manifests. -->
-
-## Expected behavior
-
-<!-- Describe what the desired behavior would be. -->
-
-## Environment
-
-- **semantic-release** version: <!-- Version set in package.json devDpendencies -->
-- CI environment: <!-- CI service name -->
-- Plugins used: <!-- List semantic-release plugin used if any -->
-- **semantic-release** configuration: <!-- link to your repository or relevant part of the semantic-release config -->
-- CI logs: <!-- link to your CI logs or semantic-release logs -->

.github/ISSUE_TEMPLATE/01_bug_report.yml

@@ -0,0 +1,51 @@
+name: Bug Report
+description: Something not working as expected
+body:
+  - type: textarea
+    attributes:
+      label: Current behavior
+      description: Describe how the issue manifests.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: Expected behavior
+      description: Describe what the desired behavior would be.
+    validations:
+      required: true
+
+  - type: input
+    attributes:
+      label: "`semantic-release` version"
+      description: Version set in `package.json` `devDpendencies`.
+    validations:
+      required: true
+
+  - type: input
+    attributes:
+      label: CI environment
+      description: CI service name.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: Plugins used
+      description: List `semantic-release` plugin used, if any.
+    validations:
+      required: false
+
+  - type: textarea
+    attributes:
+      label: "`semantic-release` configuration"
+      description: Link to your repository or relevant part of the `semantic-release` config.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: CI logs
+      description: Link to your CI logs or `semantic-release` logs.
+    validations:
+      required: true

.github/ISSUE_TEMPLATE/02_feature_request.md

@@ -1,17 +0,0 @@
----
-name: Feature request
-about: Wouldn’t it be nice if semantic-release could ...
-
----
-
-## New feature motivation
-
-<!-- Describe the context, the use-case and the advantages of the feature request. -->
-
-## New feature description
-
-<!-- Describe the functional changes that would have to be made in semantic-release or its plugins. -->
-
-## New feature implementation
-
-<!-- Optionally describe the technical changes to be made in semantic-release or its plugins. -->

.github/ISSUE_TEMPLATE/02_feature_request.yml

@@ -0,0 +1,23 @@
+name: Feature request
+description: Wouldn't it be nice if `semantic-release` could ...
+body:
+  - type: textarea
+    attributes:
+      label: New feature motivation
+      description: Describe the context, the use-case and the advantages of the feature request.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: New feature description
+      description: Describe the functional changes that would have to be made in `semantic-release` or its plugins.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: New feature implementation
+      description: Optionally describe the technical changes to be made in `semantic-release` or its plugins.
+    validations:
+      required: false

.github/ISSUE_TEMPLATE/03_plugin_suggestion.md

@@ -1,13 +0,0 @@
----
-name: New plugin suggestion
-about: Integrate with a new platform, etc
-
----
-
-## New plugin motivation
-
-<!-- Describe the reasons to create a new plugin and why it's not covered by the existing ones. -->
-
-## Third-party documentation
-
-<!-- Provide explanation and documentation links for the platform to integrate with. -->

.github/ISSUE_TEMPLATE/03_plugin_suggestion.yml

@@ -0,0 +1,16 @@
+name: New plugin suggestion
+description: Integrate with a new platform, etc
+body:
+  - type: textarea
+    attributes:
+      label: New plugin motivation
+      description: Describe the reasons to create a new plugin and why it's not covered by the existing ones.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: Third-party documentation
+      description: Provide explanation and documentation links for the platform to integrate with.
+    validations:
+      required: true

.github/workflows/test.yml

@@ -18,7 +18,8 @@ jobs:
       matrix:
         node-version:
           - 14.17
-          - 16
+          - 16.0.0
+          - 17
 
     runs-on: ubuntu-latest
 

CONTRIBUTING.md

@@ -26,39 +26,49 @@ Please follow the [Documentation guidelines](#documentation).
 
 ### Give feedback on issues
 
-Some issues are created without information requested in the [Bug report guideline](#bug-report). Help make them easier to resolve by adding any relevant information.
+Some issues are created without information requested in the [Bug report guideline](#bug-report).
+Help make them easier to resolve by adding any relevant information.
 
-Issues with the [design label](https://github.com/issues?q=is%3Aopen+is%3Aissue+user%3Asemantic-release+archived%3Afalse+label%3Adesign) are meant to discuss the implementation of new features. Participating in the discussion is a good opportunity to get involved and influence the future direction of **semantic-release**.
+Issues with the [design label](https://github.com/issues?q=is%3Aopen+is%3Aissue+user%3Asemantic-release+archived%3Afalse+label%3Adesign) are meant to discuss the implementation of new features.
+Participating in the discussion is a good opportunity to get involved and influence the future direction of **semantic-release**.
 
 ### Fix bugs and implement features
 
-Confirmed bugs and ready-to-implement features are marked with the [help wanted label](https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+user%3Asemantic-release+archived%3Afalse+label%3A%22help+wanted%22). Post a comment on an issue to indicate you would like to work on it and to request help from the [@semantic-release/maintainers](https://github.com/orgs/semantic-release/teams/contributors) and the community.
+Confirmed bugs and ready-to-implement features are marked with the [help wanted label](https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+user%3Asemantic-release+archived%3Afalse+label%3A%22help+wanted%22).
+Post a comment on an issue to indicate you would like to work on it and to request help from the [@semantic-release/maintainers](https://github.com/orgs/semantic-release/teams/contributors) and the community.
 
 ## Using the issue tracker
 
-The issue tracker is the channel for [bug reports](#bug-report), [features requests](#feature-request) and [submitting pull requests](#submitting-a-pull-request) only. Please use the [Support](docs/support/README.md) and [Get help](README.md#get-help) sections for support, troubleshooting and questions.
+The issue tracker is the channel for [bug reports](#bug-report), [features requests](#feature-request) and [submitting pull requests](#submitting-a-pull-request) only.
+Please use the [Support](docs/support/README.md) and [Get help](README.md#get-help) sections for support, troubleshooting and questions.
 
 Before opening an issue or a Pull Request, please use the [GitHub issue search](https://github.com/issues?utf8=%E2%9C%93&q=user%3Asemantic-release) to make sure the bug or feature request hasn't been already reported or fixed.
 
 ### Bug report
 
-A good bug report shouldn't leave others needing to chase you for more information. Please try to be as detailed as possible in your report and fill the information requested in the [Bug report template](https://github.com/semantic-release/semantic-release/issues/new?template=bug-report.md).
+A good bug report shouldn't leave others needing to chase you for more information.
+Please try to be as detailed as possible in your report and fill the information requested in the [bug report template](https://github.com/semantic-release/semantic-release/issues/new?template=01_bug_report.md).
 
 ### Feature request
 
-Feature requests are welcome, but take a moment to find out whether your idea fits with the scope and aims of the project. It's up to you to make a strong case to convince the project's developers of the merits of this feature. Please provide as much detail and context as possible and fill the information requested in the [Feature request template](https://github.com/semantic-release/semantic-release/issues/new?template=feature-request.md).
+Feature requests are welcome, but take a moment to find out whether your idea fits with the scope and aims of the project.
+It's up to you to make a strong case to convince the project's developers of the merits of this feature.
+Please provide as much detail and context as possible and fill the information requested in the [feature request template](https://github.com/semantic-release/semantic-release/issues/new?template=02_feature_request.md).
 
 ### New plugin request
 
-[Plugins](docs/usage/plugins.md) are a great way to extend **semantic-release** capabilities, integrate with other systems and support new project type. Please provide as much detail and context as possible and fill the information requested in the [New plugin request template](https://github.com/semantic-release/semantic-release/issues/new?template=plugin-request.md).
+[Plugins](docs/usage/plugins.md) are a great way to extend **semantic-release** capabilities, integrate with other systems and support new project type.
+Please provide as much detail and context as possible and fill the information requested in the [plugin suggestion template](https://github.com/semantic-release/semantic-release/issues/new?template=03_plugin_suggestion.md).
 
 ## Submitting a Pull Request
 
-Good pull requests, whether patches, improvements, or new features, are a fantastic help. They should remain focused in scope and avoid containing unrelated commits.
+Good pull requests, whether patches, improvements, or new features, are a fantastic help.
+They should remain focused in scope and avoid containing unrelated commits.
 
-**Please ask first** before embarking on any significant pull requests (e.g. implementing features, refactoring code), otherwise you risk spending a lot of time working on something that the project's developers might not want to merge into the project.
+**Please ask first** before embarking on any significant pull requests (e.g. implementing features, refactoring code), otherwise you risk spending a lot of time working on something that the project's maintainers might not want to merge into the project.
 
-If you have never created a pull request before, welcome 🎉 😄. [Here is a great tutorial](https://opensource.guide/how-to-contribute/#opening-a-pull-request) on how to send one :)
+If you have never created a pull request before, welcome 🎉 😄.
+[Here is a great tutorial](https://opensource.guide/how-to-contribute/#opening-a-pull-request) on how to send one :)
 
 Here is a summary of the steps to follow:
 
@@ -83,7 +93,9 @@ $ git push origin <topic-branch-name>
 
 **Tips**:
 - For ambitious tasks, open a Pull Request as soon as possible with the `[WIP]` prefix in the title, in order to get feedback and help from the community.
-- [Allow semantic-release maintainers to make changes to your Pull Request branch](https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork). This way, we can rebase it and make some minor changes if necessary. All changes we make will be done in new commit and we'll ask for your approval before merging them.
+- [Allow semantic-release maintainers to make changes to your Pull Request branch](https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork).
+  This way, we can rebase it and make some minor changes if necessary.
+  All changes we make will be done in new commit, and we'll ask for your approval before merging them.
 
 ## Coding rules
 
@@ -129,7 +141,8 @@ A complex feature can be broken down into multiple commits as long as each one m
 
 #### Commit message format
 
-Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes a **type**, a **scope** and a **subject**:
+Each commit message consists of a **header**, a **body** and a **footer**.
+The header has a special format that includes a **type**, a **scope** and a **subject**:
 
 ```commit
 <type>(<scope>): <subject>
@@ -145,7 +158,8 @@ The **footer** can contain a [closing reference to an issue](https://help.github
 
 #### Revert
 
-If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.
+If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit.
+In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.
 
 #### Type
 
@@ -178,7 +192,8 @@ The body should include the motivation for the change and contrast this with pre
 #### Footer
 The footer should contain any information about **Breaking Changes** and is also the place to reference GitHub issues that this commit **Closes**.
 
-**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit message is then used for this.
+**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines.
+The rest of the commit message is then used for this.
 
 #### Examples
 
@@ -219,7 +234,8 @@ $ npm install
 
 ### Lint
 
-All the [semantic-release](https://github.com/semantic-release) repositories use [XO](https://github.com/sindresorhus/xo) for linting and [Prettier](https://prettier.io) for formatting. Prettier formatting will be automatically verified and fixed by XO.
+All the [semantic-release](https://github.com/semantic-release) repositories use [XO](https://github.com/sindresorhus/xo) for linting and [Prettier](https://prettier.io) for formatting.
+Prettier formatting will be automatically verified and fixed by XO.
 
 Before pushing your code changes make sure there are no linting errors with `npm run lint`.
 

README.md

@@ -8,7 +8,7 @@
     <img alt="Build states" src="https://github.com/semantic-release/semantic-release/workflows/Test/badge.svg">
   </a>
   <a href="#badge">
-    <img alt="semantic-release" src="https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg">
+    <img alt="semantic-release: angular" src="https://img.shields.io/badge/semantic--release-angular-e10079?logo=semantic-release">
   </a>
 </p>
 <p align="center">
@@ -60,7 +60,7 @@ The table below shows which commit message gets you which release type when `sem
 | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------- |
 | `fix(pencil): stop graphite breaking when too much pressure applied`                                                                                                                             | ~~Patch~~ Fix Release      |
 | `feat(pencil): add 'graphiteWidth' option`                                                                                                                                                       | ~~Minor~~ Feature Release  |
-| `perf(pencil): remove graphiteWidth option`<br><br>`BREAKING CHANGE: The graphiteWidth option has been removed.`<br>`The default graphite width of 10mm is always used for performance reasons.` | ~~Major~~ Breaking Release |
+| `perf(pencil): remove graphiteWidth option`<br><br>`BREAKING CHANGE: The graphiteWidth option has been removed.`<br>`The default graphite width of 10mm is always used for performance reasons.` | ~~Major~~ Breaking Release <br /> (Note that the `BREAKING CHANGE: ` token must be in the footer of the commit) |
 
 ### Automation with CI
 
@@ -139,12 +139,13 @@ In order to use **semantic-release** you need:
 
 ## Badge
 
-Let people know that your package is published using **semantic-release** by including this badge in your readme.
+Let people know that your package is published using **semantic-release** and which [commit-convention](#commit-message-format) is followed by including this badge in your readme.
 
-[![semantic-release](https://img.shields.io/badge/semantic-release-e10079.svg?logo=semantic-release)](https://github.com/semantic-release/semantic-release)
+[![semantic-release: angular](https://img.shields.io/badge/semantic--release-angular-e10079?logo=semantic-release)](https://github.com/semantic-release/semantic-release)
 
 ```md
-[![semantic-release](https://img.shields.io/badge/semantic-release-e10079.svg?logo=semantic-release)](https://github.com/semantic-release/semantic-release)
+[![semantic-release: angular](https://img.shields.io/badge/semantic--release-angular-e10079?logo=semantic-release)](https://github.com/semantic-release/semantic-release)
+
 ```
 
 ## Team

docs/developer-guide/plugin.md

@@ -12,9 +12,9 @@ To create a plugin for `semantic-release`, you need to decide which parts of the
 - `success`
 - `fail`
 
-`semantic-release` will require the plugin via `node` and look through the required object for methods named like the lifecyles stated above. For example, if your plugin only had a `verifyConditions` and `success` step, the `main` file for your object would need to `export` an object with `verifyConditions` and `success` functions.
+`semantic-release` will require the plugin via `node` and look through the required object for methods named like the lifecycles stated above. For example, if your plugin only had a `verifyConditions` and `success` step, the `main` file for your object would need to `export` an object with `verifyConditions` and `success` functions.
 
-In addition to the lifecycle methods, each lifecyle is passed two objects:
+In addition to the lifecycle methods, each lifecycle is passed two objects:
 
 1. `pluginConfig` - an object containing the options that a user may pass in via their `release.config.js` file (or similar)
 2. `context` - provided by `semantic-release` for access to things like `env` variables set on the running process.

docs/extending/plugins-list.md

@@ -55,12 +55,12 @@
 - [@semantic-release-plus/docker](https://github.com/semantic-release-plus/semantic-release-plus/tree/master/packages/plugins/docker)
   - `verifyConditions`: Verify that all needed configuration is present and login to the configured docker registry.
   - `publish`: Tag the image specified by `name` with the new version and channel and push it to the configured docker registry.
-  - `addChannel`: Updates a release published on one channel with the destinations channel tag and pushes to the registry ie: next to latest.
+  - `addChannel`: Updates a release published on one channel with the destinations channel tag and pushes to the registry i.e.: next to latest.
 - [semantic-release-gcr](https://github.com/carlos-cubas/semantic-release-gcr)
   - `verifyConditions`: Verify that all needed configuration is present and login to the Docker registry
   - `publish`: Tag the image specified by `name` with the new version, push it to Docker Hub and update the latest tag
 - [semantic-release-vsce](https://github.com/raix/semantic-release-vsce)
-  - `verifyConditions`: Verify the presence and the validity of the vsce authentication and release configuration
+  - `verifyConditions`: Verify the presence and the validity of the "VS Code extension" authentication and release configuration
   - `prepare`: Create a `.vsix` for distribution
   - `publish`: Publish the package to the Visual Studio Code marketplace
 - [semantic-release-verify-deps](https://github.com/piercus/semantic-release-verify-deps)
@@ -84,7 +84,7 @@
   - `prepare`: Changes the version number in the `pom.xml` (or all `pom.xml` files in maven projects with multiple `pom.xml` files) and optionally creates a commit with this version number and pushes it to `master`
   - `publish`: Runs `mvn deploy` to deploy to maven central and optionally will update to next snapshot version and merge changes to development branch
 - [semantic-release-ado](https://github.com/lluchmk/semantic-release-ado)
-  - `prepare`: Stores the version number as an Azure DevOps pipeline variable availabe to downstream steps on the job
+  - `prepare`: Stores the version number as an Azure DevOps pipeline variable available to downstream steps on the job
 - [gradle-semantic-release](https://github.com/KengoTODA/gradle-semantic-release-plugin)
   - `verifyConditions`: Verify that project has a Gradle wrapper script, and `build.gradle` contains a task to publish artifacts.
   - `prepare`: Changes the version number in the `gradle.properties`
@@ -157,3 +157,12 @@
   - `verifyConditions`: Verify plugin configuration and login to Helm registry
   - `prepare`: Package Helm chart to local folder
   - `publish`: Publish Helm chart to OCI registry
+- [semantic-release-space](https://github.com/123FLO321/semantic-release-space)
+  - `verifyConditions` Verifies that all required options are set.
+  - `prepare` Creates a JetBrains Space Deployment Target if it does not yet exist.
+  - `publish` Starts a JetBrains Space Deployment.
+  - `success` Marks the JetBrains Space Deployment as completed.
+  - `fail` Marks the JetBrains Space Deployment as failed.
+- [semantic-release-react-native](https://github.com/alexandermendes/semantic-release-react-native)
+  - `verifyConditions` Validate configuration.
+  - `prepare` Version native iOS and Android files.

docs/extending/shareable-configurations-list.md

@@ -6,7 +6,7 @@
 
 ## Community configurations
 - [@jedmao/semantic-release-npm-github-config](https://github.com/jedmao/semantic-release-npm-github-config)
-  - Provides an informative [git](https://github.com/semantic-release/git) commit message for the release commit that does not trigger continuous integration and conforms to the [conventional commits specification](https://www.conventionalcommits.org/) (e.g., "chore(release): 1.2.3 [skip ci]\n\nnotes").
+  - Provides an informative [Git](https://github.com/semantic-release/git) commit message for the release commit that does not trigger continuous integration and conforms to the [conventional commits specification](https://www.conventionalcommits.org/) (e.g., `chore(release): 1.2.3 [skip ci]\n\nnotes`).
   - Creates a tarball that gets uploaded with each [GitHub release](https://github.com/semantic-release/github).
   - Publishes the same tarball to [npm](https://github.com/semantic-release/npm).
   - Commits the version change in `package.json`.
@@ -18,4 +18,3 @@
   - Updates GitHub release with release-notes.
   - Bumps a version in package.json.
   - Publishes the new version to [NPM](https://npmjs.org).
-  

docs/recipes/ci-configurations/circleci-workflows.md

@@ -22,14 +22,12 @@ Finally, we call our release job with a `requires` parameter so that `release` w
 ```yaml
 version: 2.1
 orbs:
-  node: circleci/node@4.5
+  node: circleci/node@5.0.0
 jobs:
   release:
     executor: node/default
     steps:
       - checkout
-      - node/install
-          lts: true
       - node/install-packages # Install and automatically cache packages
       # Run optional required steps before releasing
       # - run: npm run build-script

docs/recipes/ci-configurations/gitlab-ci.md

@@ -14,7 +14,7 @@ GitLab CI supports [Pipelines](https://docs.gitlab.com/ee/ci/pipelines.html) all
 
 ### `.gitlab-ci.yml` configuration for Node projects
 
-This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. See [GitLab CI - Configuration of your jobs with .gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options.
+This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. See [GitLab CI - Configuration of your jobs with `.gitlab-ci.yml`](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options.
 
 **Note**: The`semantic-release` execution command varies depending on whether you are using a [local](../../usage/installation.md#local-installation) or [global](../../usage/installation.md#global-installation) **semantic-release** installation.
 
@@ -48,7 +48,7 @@ publish:
 
 ### `.gitlab-ci.yml` configuration for all projects
 
-This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. See [GitLab CI - Configuration of your jobs with .gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options.
+This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. See [GitLab CI - Configuration of your jobs with `.gitlab-ci.yml`](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options.
 
 **Note**: The`semantic-release` execution command varies depending if you are using a [local](../../usage/installation.md#local-installation) or [global](../../usage/installation.md#global-installation) **semantic-release** installation.
 
@@ -66,8 +66,8 @@ release:
     - npm install -g semantic-release @semantic-release/gitlab
   script:
     - semantic-release
-  only:
-    - master
+  rules:
+    - if: $CI_COMMIT_BRANCH == "master"
 
 release:
   image: node:12-buster-slim
@@ -77,8 +77,8 @@ release:
     - npm install -g semantic-release @semantic-release/gitlab
   script:
     - semantic-release
-  only:
-    - master
+  rules:
+    - if: $CI_COMMIT_BRANCH == "master"
 ```
 
 ### `package.json` configuration

docs/recipes/release-workflow/distribution-channels.md

@@ -1,6 +1,6 @@
 # Publishing on distribution channels
 
-This recipe will walk you through a simple example that uses distribution channels to make releases available only to a subset of users, in order to collect feedbacks before distributing the release to all users.
+This recipe will walk you through a simple example that uses distribution channels to make releases available only to a subset of users, in order to collect feedback before distributing the release to all users.
 
 This example uses the **semantic-release** default configuration:
 - [branches](../../usage/configuration.md#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]`

docs/support/FAQ.md

@@ -44,7 +44,7 @@ Yes, **semantic-release** is a Node CLI application, but it can be used to publi
 
 To publish a non-Node package (without a `package.json`) you would need to:
 - Use a [global](../usage/installation.md#global-installation) **semantic-release** installation
-- Set **semantic-release** [options](../usage/configuration.md#options) via [CLI arguments or rc file](../usage/configuration.md#configuration)
+- Set **semantic-release** [options](../usage/configuration.md#options) via [CLI arguments or `.rc` file](../usage/configuration.md#configuration)
 - Make sure your CI job executing the `semantic-release` command has access to a version of Node that [meets our version requirement](./node-version.md) to execute the `semantic-release` command
 
 See the [CI configuration recipes](../recipes/release-workflow/README.md#ci-configurations) for more details on specific CI environments.
@@ -153,7 +153,7 @@ Any npm compatible registry is supported with the [`@semantic-release/npm`](http
 
 See [npm registry authentication](https://github.com/semantic-release/npm#npm-registry-authentication) for more details.
 
-See [Artifactory - npm Registry](https://www.jfrog.com/confluence/display/RTF/Npm+Registry#NpmRegistry-AuthenticatingthenpmClient) documentation for Artifactiry configuration.
+See [Artifactory - npm Registry](https://www.jfrog.com/confluence/display/RTF/Npm+Registry#NpmRegistry-AuthenticatingthenpmClient) documentation for Artifactory configuration.
 
 ## Can I manually trigger the release of a specific version?
 

docs/support/node-version.md

@@ -1,6 +1,6 @@
 # Node version requirement
 
-**semantic-release** is written using the latest [ECMAScript 2017](https://www.ecma-international.org/publications/standards/Ecma-262.htm) features, without transpilation which requires **requires Node version 14.17 or higher**.
+**semantic-release** is written using the latest [ECMAScript 2017](https://www.ecma-international.org/publications/standards/Ecma-262.htm) features, without transpilation which **requires Node version 14.17 or higher**.
 
 **semantic-release** is meant to be used in a CI environment as a development support tool, not as a production dependency.
 Therefore, the only constraint is to run the `semantic-release` in a CI environment providing version of Node that meets our version requirement.

docs/usage/ci-configuration.md

@@ -13,7 +13,7 @@ Here is a few example of the CI services that can be used to achieve this:
 - [Wercker Workflows](http://devcenter.wercker.com/docs/workflows)
 - [GoCD Pipelines](https://docs.gocd.org/current/introduction/concepts_in_go.html#pipeline).
 
-See [CI configuration recipes](../recipes/release-workflow/README.md#ci-configurations) for more details.
+See [CI configuration recipes](../recipes/ci-configurations#ci-configurations) for more details.
 
 ## Authentication
 
@@ -26,7 +26,7 @@ See [CI configuration recipes](../recipes/release-workflow/README.md#ci-configur
 | `GH_TOKEN` or `GITHUB_TOKEN`                          | A GitHub [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line).                                                                                                    |
 | `GL_TOKEN` or `GITLAB_TOKEN`                          | A GitLab [personal access token](https://docs.gitlab.com/ce/user/profile/personal_access_tokens.html).                                                                                                                       |
 | `BB_TOKEN` or `BITBUCKET_TOKEN`                       | A Bitbucket [personal access token](https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html).                                                                                                 |
-| `BB_TOKEN_BASIC_AUTH` or `BITBUCKET_TOKEN_BASIC_AUTH` | A Bitbucket [personal access token](https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html) with basic auth support. For clearification `user:token` has to be the value of this env.        |
+| `BB_TOKEN_BASIC_AUTH` or `BITBUCKET_TOKEN_BASIC_AUTH` | A Bitbucket [personal access token](https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html) with basic auth support. For clarification `user:token` has to be the value of this env.        |
 | `GIT_CREDENTIALS`                                     | [URL encoded](https://en.wikipedia.org/wiki/Percent-encoding) Git username and password in the format `<username>:<password>`. The username and password must each be individually URL encoded, not the `:` separating them. |
 
 Alternatively the Git authentication can be set up via [SSH keys](../recipes/git-hosted-services/git-auth-ssh-keys.md).
@@ -44,6 +44,6 @@ See each plugin's documentation for the environment variables required.
 
 The authentication token/credentials have to be made available in the CI service via environment variables.
 
-See [CI configuration recipes](../recipes/release-workflow/README.md#ci-configurations) for more details on how to configure environment variables in your CI service.
+See [CI configuration recipes](../recipes/ci-configurations#ci-configurations) for more details on how to configure environment variables in your CI service.
 
 **Note**: The environment variables `GH_TOKEN`, `GITHUB_TOKEN`, `GL_TOKEN` and `GITLAB_TOKEN` can be used for both the Git authentication and the API authentication required by [@semantic-release/github](https://github.com/semantic-release/github) and [@semantic-release/gitlab](https://github.com/semantic-release/gitlab).

docs/usage/configuration.md

@@ -69,8 +69,8 @@ The branches on which releases should happen. By default **semantic-release** wi
 - regular releases to a distribution channel matching the branch name from any existing branch with a name matching a maintenance release range (`N.N.x` or `N.x.x` or `N.x` with `N` being a number)
 - regular releases to the `next` distribution channel from the branch `next` if it exists
 - regular releases  to the `next-major` distribution channel from the branch `next-major` if it exists
-- prereleases to the `beta` distribution channel from the branch `beta` if it exists
-- prereleases to the `alpha` distribution channel from the branch `alpha` if it exists
+- pre-releases to the `beta` distribution channel from the branch `beta` if it exists
+- pre-releases to the `alpha` distribution channel from the branch `alpha` if it exists
 
 **Note**: If your repository does not have a release branch, then **semantic-release** will fail with an `ERELEASEBRANCHES` error message. If you are using the default configuration, you can fix this error by pushing a `master` branch.
 
@@ -116,7 +116,7 @@ Type: `Boolean`<br>
 Default: `false` if running in a CI environment, `true` otherwise<br>
 CLI arguments: `-d`, `--dry-run`
 
-The objective of the dry-run mode is to get a preview of the pending release. Dry-run mode skips the following steps: prepare, publish, success and fail. In addition to this it prints the next version and release notes to the console.
+The objective of the dry-run mode is to get a preview of the pending release. Dry-run mode skips the following steps: prepare, publish, addChannel, success and fail. In addition to this it prints the next version and release notes to the console.
 
 **Note**: The Dry-run mode verifies the repository push permission, even though nothing will be pushed. The verification is done to help user to figure out potential configuration issues.
 

docs/usage/installation.md

@@ -24,7 +24,7 @@ For other type of projects we recommend installing **semantic-release** directly
 $ npx semantic-release
 ```
 
-**Note**: For a global installation, it's recommended to specify the major **semantic-release** version to install (for example with with `npx semantic-release@18`).
+**Note**: For a global installation, it's recommended to specify the major **semantic-release** version to install (for example with `npx semantic-release@18`).
 This way your build will not automatically use the next major **semantic-release** release that could possibly break your build.
 You will have to upgrade manually when a new major version is released.
 

docs/usage/workflow-configuration.md

@@ -1,7 +1,7 @@
 # Workflow configuration
 
 **semantic-release** allow to manage and automate complex release workflow, based on multiple Git branches and distribution channels. This allow to:
-- Distributes certain releases to a particular group of users via distribution channels
+- Distribute certain releases to a particular group of users via distribution channels
 - Manage the availability of releases on distribution channels via branches merge
 - Maintain multiple lines of releases in parallel
 - Work on large future releases outside the normal flow of one version increment per Git push
@@ -91,7 +91,7 @@ For example the configuration `['master', {name: 'pre/rc', prerelease: '${name.r
   branches: [
     {name: 'master'},
     {name: 'pre/rc', channel: 'pre/rc', prerelease: 'rc'}, // `prerelease` is built with the template `${name.replace(/^pre\\//g, "")}`
-    {name: 'beta', channel: 'beta', prerelease: 'beta'}, // `prerelease` is set to `beta` as it is the value of `name`
+    {name: 'beta', channel: 'beta', prerelease: true}, // `prerelease` is set to `beta` as it is the value of `name`
   ]
 }
 ```

index.js

@@ -1,6 +1,5 @@
 const {pick} = require('lodash');
 const marked = require('marked');
-const TerminalRenderer = require('marked-terminal');
 const envCi = require('env-ci');
 const hookStd = require('hook-std');
 const semver = require('semver');
@@ -21,7 +20,16 @@ const {verifyAuth, isBranchUpToDate, getGitHead, tag, push, pushNotes, getTagHea
 const getError = require('./lib/get-error');
 const {COMMIT_NAME, COMMIT_EMAIL} = require('./lib/definitions/constants');
 
-marked.setOptions({renderer: new TerminalRenderer()});
+let markedOptionsSet = false;
+async function terminalOutput(text) {
+  if (!markedOptionsSet) {
+    const {default: TerminalRenderer} = await import('marked-terminal'); // eslint-disable-line node/no-unsupported-features/es-syntax
+    marked.setOptions({renderer: new TerminalRenderer()});
+    markedOptionsSet = true;
+  }
+
+  return marked.parse(text);
+}
 
 /* eslint complexity: off */
 async function run(context, plugins) {
@@ -67,7 +75,7 @@ async function run(context, plugins) {
   }
 
   logger[options.dryRun ? 'warn' : 'success'](
-    `Run automated release from branch ${ciBranch} on repository ${options.repositoryUrl}${
+    `Run automated release from branch ${ciBranch} on repository ${options.originalRepositoryURL}${
       options.dryRun ? ' in dry-run mode' : ''
     }`
   );
@@ -207,20 +215,20 @@ async function run(context, plugins) {
   if (options.dryRun) {
     logger.log(`Release note for version ${nextRelease.version}:`);
     if (nextRelease.notes) {
-      context.stdout.write(marked(nextRelease.notes));
+      context.stdout.write(await terminalOutput(nextRelease.notes));
     }
   }
 
   return pick(context, ['lastRelease', 'commits', 'nextRelease', 'releases']);
 }
 
-function logErrors({logger, stderr}, err) {
+async function logErrors({logger, stderr}, err) {
   const errors = extractErrors(err).sort((error) => (error.semanticRelease ? -1 : 0));
   for (const error of errors) {
     if (error.semanticRelease) {
       logger.error(`${error.code} ${error.message}`);
       if (error.details) {
-        stderr.write(marked(error.details));
+        stderr.write(await terminalOutput(error.details)); // eslint-disable-line no-await-in-loop
       }
     } else {
       logger.error('An error occurred while running semantic-release: %O', error);
@@ -234,7 +242,7 @@ async function callFail(context, plugins, err) {
     try {
       await plugins.fail({...context, errors});
     } catch (error) {
-      logErrors(context, error);
+      await logErrors(context, error);
     }
   }
 }
@@ -255,6 +263,7 @@ module.exports = async (cliOptions = {}, {cwd = process.cwd(), env = process.env
   context.logger.log(`Running ${pkg.name} version ${pkg.version}`);
   try {
     const {plugins, options} = await getConfig(context, cliOptions);
+    options.originalRepositoryURL = options.repositoryUrl;
     context.options = options;
     try {
       const result = await run(context, plugins);
@@ -265,7 +274,7 @@ module.exports = async (cliOptions = {}, {cwd = process.cwd(), env = process.env
       throw error;
     }
   } catch (error) {
-    logErrors(context, error);
+    await logErrors(context, error);
     unhook();
     throw error;
   }

lib/branches/index.js

@@ -27,6 +27,7 @@ module.exports = async (repositoryUrl, ciBranch, context) => {
 
   const errors = [];
   const branchesByType = Object.entries(DEFINITIONS).reduce(
+    // eslint-disable-next-line unicorn/no-fn-reference-in-iterator
     (branchesByType, [type, {filter}]) => ({[type]: branches.filter(filter), ...branchesByType}),
     {}
   );

lib/definitions/branches.js

@@ -16,6 +16,7 @@ const prerelease = {
 };
 
 const release = {
+  // eslint-disable-next-line unicorn/no-fn-reference-in-iterator
   filter: (branch) => !maintenance.filter(branch) && !prerelease.filter(branch),
   branchesValidator: (branches) => branches.length <= 3 && branches.length > 0,
 };

lib/get-git-auth-url.js

@@ -89,7 +89,7 @@ module.exports = async (context) => {
   try {
     debug('Verifying ssh auth by attempting to push to  %s', repositoryUrl);
     await verifyAuth(repositoryUrl, branch.name, {cwd, env});
-  } catch (_) {
+  } catch {
     debug('SSH key auth failed, falling back to https.');
     const envVars = Object.keys(GIT_TOKENS).filter((envVar) => !isNil(env[envVar]));
 

lib/git.js

@@ -116,7 +116,7 @@ async function fetch(repositoryUrl, branch, ciBranch, execaOptions) {
       ],
       execaOptions
     );
-  } catch (_) {
+  } catch {
     await execa(
       'git',
       [
@@ -144,7 +144,7 @@ async function fetchNotes(repositoryUrl, execaOptions) {
       ['fetch', '--unshallow', repositoryUrl, `+refs/notes/${GIT_NOTE_REF}:refs/notes/${GIT_NOTE_REF}`],
       execaOptions
     );
-  } catch (_) {
+  } catch {
     await execa('git', ['fetch', repositoryUrl, `+refs/notes/${GIT_NOTE_REF}:refs/notes/${GIT_NOTE_REF}`], {
       ...execaOptions,
       reject: false,

package.json

@@ -23,7 +23,7 @@
     "@semantic-release/commit-analyzer": "^9.0.2",
     "@semantic-release/error": "^3.0.0",
     "@semantic-release/github": "^8.0.0",
-    "@semantic-release/npm": "^8.0.0",
+    "@semantic-release/npm": "^9.0.0",
     "@semantic-release/release-notes-generator": "^10.0.0",
     "aggregate-error": "^3.0.0",
     "cosmiconfig": "^7.0.0",
@@ -37,8 +37,8 @@
     "hook-std": "^2.0.0",
     "hosted-git-info": "^4.0.0",
     "lodash": "^4.17.21",
-    "marked": "^2.0.0",
-    "marked-terminal": "^4.1.1",
+    "marked": "^4.0.10",
+    "marked-terminal": "^5.0.0",
     "micromatch": "^4.0.2",
     "p-each-series": "^2.1.0",
     "p-reduce": "^2.0.0",
@@ -57,7 +57,7 @@
     "dockerode": "3.3.1",
     "file-url": "3.0.0",
     "fs-extra": "9.1.0",
-    "got": "11.8.3",
+    "got": "11.8.5",
     "js-yaml": "4.1.0",
     "mockserver-client": "5.11.2",
     "nock": "13.2.1",
@@ -67,10 +67,10 @@
     "sinon": "12.0.1",
     "stream-buffers": "3.0.2",
     "tempy": "1.0.1",
-    "xo": "0.29.1"
+    "xo": "0.32.1"
   },
   "engines": {
-    "node": ">=14.17"
+    "node": ">=16 || ^14.17"
   },
   "files": [
     "bin",
@@ -129,6 +129,7 @@
     "prettier": true,
     "space": true,
     "rules": {
+      "unicorn/no-reduce": "off",
       "unicorn/string-content": "off"
     }
   },

test/definitions/branches.test.js

@@ -2,6 +2,7 @@ const test = require('ava');
 const {maintenance, prerelease, release} = require('../../lib/definitions/branches');
 
 test('A "maintenance" branch is identified by having a "range" property or a "name" formatted like "N.x", "N.x.x" or "N.N.x"', (t) => {
+  /* eslint-disable unicorn/no-fn-reference-in-iterator */
   t.true(maintenance.filter({name: '1.x.x'}));
   t.true(maintenance.filter({name: '1.0.x'}));
   t.true(maintenance.filter({name: '1.x'}));
@@ -15,6 +16,7 @@ test('A "maintenance" branch is identified by having a "range" property or a "na
   t.false(maintenance.filter({name: 'some-name'}));
   t.false(maintenance.filter({name: '1.0.0'}));
   t.false(maintenance.filter({name: 'x.x.x'}));
+  /* eslint-enable unicorn/no-fn-reference-in-iterator */
 });
 
 test('A "maintenance" branches must have a "range" property formatted like "N.x", "N.x.x" or "N.N.x"', (t) => {
@@ -37,6 +39,7 @@ test('The "maintenance" branches must have unique ranges', (t) => {
 });
 
 test('A "prerelease" branch is identified by having a thruthy "prerelease" property', (t) => {
+  /* eslint-disable unicorn/no-fn-reference-in-iterator */
   t.true(prerelease.filter({name: 'some-name', prerelease: true}));
   t.true(prerelease.filter({name: 'some-name', prerelease: 'beta'}));
   t.true(prerelease.filter({name: 'some-name', prerelease: ''}));
@@ -44,6 +47,7 @@ test('A "prerelease" branch is identified by having a thruthy "prerelease" prope
   t.false(prerelease.filter({name: 'some-name', prerelease: null}));
   t.false(prerelease.filter({name: 'some-name', prerelease: false}));
   t.false(prerelease.filter({name: 'some-name'}));
+  /* eslint-enable unicorn/no-fn-reference-in-iterator */
 });
 
 test('A "prerelease" branch must have a valid prerelease detonation in "prerelease" property or in "name" if "prerelease" is "true"', (t) => {
@@ -66,6 +70,7 @@ test('The "prerelease" branches must have unique "prerelease" property', (t) =>
 });
 
 test('A "release" branch is identified by not havin a "range" or "prerelease" property or a "name" formatted like "N.x", "N.x.x" or "N.N.x"', (t) => {
+  /* eslint-disable unicorn/no-fn-reference-in-iterator */
   t.true(release.filter({name: 'some-name'}));
 
   t.false(release.filter({name: '1.x.x'}));
@@ -74,6 +79,7 @@ test('A "release" branch is identified by not havin a "range" or "prerelease" pr
   t.false(release.filter({name: 'some-name', range: '1.1.x'}));
   t.false(release.filter({name: 'some-name', prerelease: true}));
   t.false(release.filter({name: 'some-name', prerelease: 'beta'}));
+  /* eslint-enable unicorn/no-fn-reference-in-iterator */
 });
 
 test('There must be between 1 and 3 release branches', (t) => {

test/helpers/gitbox.js

@@ -3,7 +3,7 @@ const getStream = require('get-stream');
 const pRetry = require('p-retry');
 const {initBareRepo, gitShallowClone} = require('./git-utils');
 
-const IMAGE = 'pvdlg/docker-gitbox:latest';
+const IMAGE = 'semanticrelease/docker-gitbox:latest';
 const SERVER_PORT = 80;
 const HOST_PORT = 2080;
 const SERVER_HOST = 'localhost';

test/helpers/mockserver.js

@@ -30,13 +30,13 @@ async function start() {
       minTimeout: 1000,
       factor: 2,
     });
-  } catch (_) {
+  } catch {
     throw new Error(`Couldn't start mock-server after 2 min`);
   }
 }
 
 /**
- * Stop and remote the `mockserver` Docker container.
+ * Stop and remove the `mockserver` Docker container.
  */
 async function stop() {
   await container.stop();
@@ -91,7 +91,7 @@ async function mock(
 }
 
 /**
- * Verify the `mockserver` has been called with a requestion matching expectations. The `expectation` is created with the `mock` function.
+ * Verify the `mockserver` has been called with a request matching expectations. The `expectation` is created with the `mock` function.
  *
  * @param {Object} expectation The expectation created with `mock` function.
  * @return {Promise} A Promise that resolves if the expectation is met or reject otherwise.

test/helpers/npm-registry.js

@@ -37,7 +37,7 @@ async function start() {
       minTimeout: 1000,
       factor: 2,
     });
-  } catch (_) {
+  } catch {
     throw new Error(`Couldn't start npm-registry-docker after 2 min`);
   }
 

test/index.test.js

@@ -90,6 +90,7 @@ test('Plugins are called with expected values', async (t) => {
   const config = {
     branches: [{name: 'master'}, {name: 'next'}],
     repositoryUrl,
+    originalRepositoryURL: repositoryUrl,
     globalOpt: 'global',
     tagFormat: `v\${version}`,
   };
@@ -927,7 +928,12 @@ test('Log all "verifyConditions" errors', async (t) => {
   const error2 = new SemanticReleaseError('error 2', 'ERR2');
   const error3 = new SemanticReleaseError('error 3', 'ERR3');
   const fail = stub().resolves();
-  const config = {branches: [{name: 'master'}], repositoryUrl, tagFormat: `v\${version}`};
+  const config = {
+    branches: [{name: 'master'}],
+    repositoryUrl,
+    originalRepositoryURL: repositoryUrl,
+    tagFormat: `v\${version}`,
+  };
   const options = {
     ...config,
     plugins: false,