fix(plugins): upgraded to the beta versions of the commit-analyzer and release-notes-generator plugins

for #2055

.github/workflows/test.yml

@@ -17,9 +17,8 @@ jobs:
     strategy:
       matrix:
         node-version:
-          - 10.18.0
-          - 12
-          - 14
+          - 14.17
+          - 16
 
     runs-on: ubuntu-latest
 
@@ -32,8 +31,6 @@ jobs:
         with:
           node-version: ${{ matrix.node-version }}
           cache: npm
-      - name: Ensure dependencies are compatible with the version of node
-        run: echo 'engine-strict=true' >> .npmrc
       - run: npm ci
       - run: npm run test:ci
 
@@ -46,6 +43,9 @@ jobs:
       - uses: actions/checkout@v2
       - uses: actions/setup-node@v2
         with:
+          node-version: 16
           cache: npm
       - run: npm ci
+      - name: Ensure dependencies are compatible with the version of node
+        run: npx ls-engines@0.4
       - run: npm run lint

README.md

@@ -97,7 +97,7 @@ In order to use **semantic-release** you need:
 - To host your code in a [Git repository](https://git-scm.com)
 - Use a Continuous Integration service that allows you to [securely set up credentials](docs/usage/ci-configuration.md#authentication)
 - Git CLI version [2.7.1 or higher](docs/support/FAQ.md#why-does-semantic-release-require-git-version--271) installed in your Continuous Integration environment
-- [Node.js](https://nodejs.org) version [10.18 or higher](docs/support/FAQ.md#why-does-semantic-release-require-node-version--1018) installed in your Continuous Integration environment
+- [Node.js](https://nodejs.org) version [14.17 or higher](docs/support/FAQ.md#why-does-semantic-release-require-node-version--1417) installed in your Continuous Integration environment
 
 ## Documentation
 

docs/recipes/circleci-workflows.md

@@ -39,7 +39,7 @@ workflows:
             parameters:
               version:
                 - 16.1.0
-                - 14.7.0
+                - 14.17.0
       - release:
           requires:
             - node/test
@@ -52,7 +52,7 @@ A `package.json` is required only for [local](../usage/installation.md#local-ins
 ```json
 {
   "devDependencies": {
-    "semantic-release": "^15.0.0"
+    "semantic-release": "^18.0.0"
   }
 }
 ```

docs/recipes/github-actions.md

@@ -10,11 +10,12 @@ In this example a publish type [`NPM_TOKEN`](https://docs.npmjs.com/creating-and
 
 [GitHub Actions](https://github.com/features/actions) support [Workflows](https://help.github.com/en/articles/configuring-workflows), allowing to run tests on multiple Node versions and publish a release only when all test pass.
 
-**Note**: The publish pipeline must run on [Node version >= 10.18](../support/FAQ.md#why-does-semantic-release-require-node-version--1018).
+**Note**: The publish pipeline must run on [Node version >= 14.17](../support/FAQ.md#why-does-semantic-release-require-node-version--1417).
 
 ### `.github/workflows/release.yml` configuration for Node projects
 
-The following is a minimal configuration for [`semantic-release`](https://github.com/semantic-release/semantic-release) with a build running on Node 12 when a new commit is pushed to a `master` branch. See [Configuring a Workflow](https://help.github.com/en/articles/configuring-a-workflow) for additional configuration options.
+The following is a minimal configuration for [`semantic-release`](https://github.com/semantic-release/semantic-release) with a build running on Node 14.17 when a new commit is pushed to a `master` branch.
+See [Configuring a Workflow](https://help.github.com/en/articles/configuring-a-workflow) for additional configuration options.
 
 ```yaml
 name: Release
@@ -34,7 +35,7 @@ jobs:
       - name: Setup Node.js
         uses: actions/setup-node@v1
         with:
-          node-version: 12
+          node-version: '14.17'
       - name: Install dependencies
         run: npm ci
       - name: Release

docs/recipes/gitlab-ci.md

@@ -10,7 +10,7 @@ The [Authentication](../usage/ci-configuration.md#authentication) environment va
 
 GitLab CI supports [Pipelines](https://docs.gitlab.com/ee/ci/pipelines.html) allowing to test on multiple Node versions and publishing a release only when all test pass.
 
-**Note**: The publish pipeline must run a [Node >= 10.18 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1018).
+**Note**: The publish pipeline must run a [Node >= 14.17 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1417).
 
 ### `.gitlab-ci.yml` configuration for Node projects
 
@@ -54,7 +54,7 @@ This example is a minimal configuration for **semantic-release** with a build ru
 
 
 ```yaml
-# The release pipeline will run only on the master branch a commit is triggered 
+# The release pipeline will run only on the master branch a commit is triggered
 stages:
   - release
 

docs/recipes/jenkins-ci.md

@@ -10,16 +10,16 @@ Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with
 
 ### `Jenkinsfile (Declarative Pipeline)` configuration for a Node.js job
 
-**Note**: The publish pipeline must run a [Node >= 10.18 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1018).
+**Note**: The publish pipeline must run a [Node >= 14.17 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1417).
 
-This example is a minimal configuration for **semantic-release** with a build running Node 10.18. See [Jenkins documentation](https://www.jenkins.io/doc/) for additional configuration options.
+This example is a minimal configuration for **semantic-release** with a build running Node 14.17. See [Jenkins documentation](https://www.jenkins.io/doc/) for additional configuration options.
 
 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.
 
 ```yaml
 // The release stage in the pipeline will run only if the test stage in the pipeline is successful
 pipeline {
-    agent any 
+    agent any
     environment {
         GH_TOKEN  = credentials('some-id')
     }
@@ -35,14 +35,14 @@ pipeline {
         }
         stage('Release') {
             tools {
-            nodejs "node 10.18"
+            nodejs "node 14.17"
             }
             steps {
                 sh '''
                 # Run optional required steps before releasing
                 npx semantic-release
                 '''
-            }            
+            }
         }
     }
 }
@@ -55,7 +55,7 @@ A `package.json` is required only for [local](../usage/installation.md#local-ins
 ```json
 {
   "devDependencies": {
-    "semantic-release": "^15.0.0"
+    "semantic-release": "^18.0.0"
   }
 }
 ```

docs/recipes/travis.md

@@ -10,7 +10,7 @@ Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with
 
 ### `.travis.yml` configuration for multiple Node.js jobs
 
-This example is a minimal configuration for **semantic-release** with a build running Node 6 and 8. See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options.
+This example is a minimal configuration for **semantic-release** with a build running Node 14 and 16. See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options.
 
 This example creates a `release` [build stage](https://docs.travis-ci.com/user/build-stages) that [runs `semantic-release` only after all test jobs are successful](../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded).
 
@@ -24,8 +24,8 @@ It's recommended to run the `semantic-release` command in the [Travis `deploy` s
 language: node_js
 
 node_js:
-  - 8
-  - 6
+  - 14
+  - 16
 
 jobs:
   include:
@@ -48,7 +48,7 @@ A `package.json` is required only for [local](../usage/installation.md#local-ins
 ```json
 {
   "devDependencies": {
-    "semantic-release": "^15.0.0"
+    "semantic-release": "^18.0.0"
   }
 }
 ```

docs/support/FAQ.md

@@ -38,44 +38,14 @@ If using npm hook scripts is not possible, and alternative solution is to [`@sem
 
 Yes with the [dry-run options](../usage/configuration.md#dryrun) which prints to the console the next version to be published and the release notes.
 
-## Can I use semantic-release with Yarn?
-
-If you are using a [local](../usage/installation.md#local-installation) **semantic-release** installation and run multiple CI jobs with different versions, the `yarn install` command will fail on jobs running with Node < 8 as **semantic-release** requires [Node >= 10.18](#why-does-semantic-release-require-node-version--1018) and specifies it in its `package.json`s [`engines`](https://docs.npmjs.com/files/package.json#engines) key.
-
-The recommended solution is to use the [Yarn](https://yarnpkg.com) [--ignore-engines](https://yarnpkg.com/en/docs/cli/install#toc-yarn-install-ignore-engines) option to install the project dependencies on the CI environment, so Yarn will ignore the **semantic-release**'s `engines` key:
-
-```bash
-$ yarn install --ignore-engines
-```
-
-**Note**: Several CI services use Yarn by default if your repository contains a `yarn.lock` file. So you should override the install step to specify `yarn install --ignore-engines`.
-
-Alternatively you can use a [global](../usage/installation.md#global-installation) **semantic-release** installation and make sure to install and run the `semantic-release` command only in a CI jobs running with Node >= 10.18.
-
-If your CI environment provides [nvm](https://github.com/creationix/nvm) you can switch to Node 8 before installing and running the `semantic-release` command:
-
-```bash
-$ nvm install 8 && yarn global add semantic-release && semantic-release
-```
-
-See the [CI configuration recipes](../recipes/README.md#ci-configurations) for more details on specific CI environments.
-
-As `semantic-release` is recommended to be executed with [`npx`](https://www.npmjs.com/package/npx) an alternative is required for usage with Yarn. Even though it is possible to install npx with Yarn, it's not recommended. Yarn and npx would be using different cache locations.
-
-For [local installation](../usage/installation.md#local-installation) replace
-`npx semantic-release` with `yarn run semantic-release`.
-
-For [global installation](../usage/installation.md#global-installation) replace
-`npx semantic-release` with `yarn global add semantic-release && semantic-release`.
-
 ## Can I use semantic-release to publish non-JavaScript packages?
 
-Yes, **semantic-release** is a Node CLI application but it can be used to publish any type of packages.
+Yes, **semantic-release** is a Node CLI application, but it can be used to publish any type of packages.
 
 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)
-- Make sure your CI job executing the `semantic-release` command has access to [Node >= 10.18](#why-does-semantic-release-require-node-version--1018) to execute the `semantic-release` command
+- Make sure your CI job executing the `semantic-release` command has access to [Node >= 14.17](#why-does-semantic-release-require-node-version--1417) to execute the `semantic-release` command
 
 See the [CI configuration recipes](../recipes/README.md#ci-configurations) for more details on specific CI environments.
 
@@ -234,9 +204,9 @@ See [“Introduction to SemVer” - Irina Gebauer](https://blog.greenkeeper.io/i
 
 In addition the [verify conditions step](../../README.md#release-steps) verifies that all necessary conditions for proceeding with a release are met, and a new release will be performed [only if all your tests pass](../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded).
 
-## Why does semantic-release require Node version >= 10.18?
+## Why does semantic-release require Node version >= 14.17?
 
-**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 10.18 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**.
 
 See [Node version requirement](./node-version.md#node-version-requirement) for more details and solutions.
 

docs/support/node-support-policy.md

@@ -1,6 +1,6 @@
 # Node Support Policy
 
-We only support [Long-Term Support](https://github.com/nodejs/Release) versions of Node starting with [Node 8.9.0 (LTS)](https://nodejs.org/en/blog/release/v8.9.0).
+We only support [Long-Term Support](https://github.com/nodejs/Release) versions of Node starting with [Node 14.17.0 (LTS)](https://nodejs.org/en/blog/release/v14.17.0).
 
 We specifically limit our support to LTS versions of Node, not because this package won't work on other versions, but because we have a limited amount of time, and supporting LTS offers the greatest return on that investment.
 

docs/support/node-version.md

@@ -1,16 +1,17 @@
 # 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 10 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 **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 Node 8 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 Node 14.17 or higher.
 
 See our [Node Support Policy](node-support-policy.md) for our long-term promise regarding Node version support.
 
 ## Recommended solution
 
-### Run at least one CI job with Node >= 10.18
+### Run at least one CI job with Node >= 14.17
 
-The recommended approach is to run the `semantic-release` command from a CI job running on Node 10.18 or higher. This can either be a job used by your project to test on Node >= 10.18 or a dedicated job for the release steps.
+The recommended approach is to run the `semantic-release` command from a CI job running on Node 14.17 or higher.
+This can either be a job used by your project to test on Node >= 14.17 or a dedicated job for the release steps.
 
 See [CI configuration](../usage/ci-configuration.md) and [CI configuration recipes](../recipes/README.md#ci-configurations) for more details.
 
@@ -18,18 +19,19 @@ See [CI configuration](../usage/ci-configuration.md) and [CI configuration recip
 
 ### Use `npx`
 
-`npx` is included with npm >= 5.2 and can be used to download the latest [Node 8 package published on npm](https://www.npmjs.com/package/node). Use it to execute the `semantic-release` command.
+`npx` is included with npm >= 5.2 and can be used to download the latest [Node 14 package published on npm](https://www.npmjs.com/package/node).
+Use it to execute the `semantic-release` command.
 
 ```bash
-$ npx -p node@8 -c "npx semantic-release"
+$ npx -p node@14 -c "npx semantic-release"
 ```
 
 **Note:**: See [What is npx](./FAQ.md#what-is-npx) for more details.
 
 ### Use `nvm`
 
-If your CI environment provides [nvm](https://github.com/creationix/nvm) you can use it to switch to Node 8 before running the `semantic-release` command.
+If your CI environment provides [nvm](https://github.com/creationix/nvm) you can use it to switch to Node 14.17 before running the `semantic-release` command.
 
 ```bash
-$ nvm install 8 && npx semantic-release
+$ nvm install 14.17 && npx semantic-release
 ```

docs/usage/installation.md

@@ -24,6 +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@15`). 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.
+**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`).
+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.
 
 **Note**: `npx` is a tool bundled with `npm@>=5.2.0`. It is used to conveniently install the semantic-release binary and to execute it. See [What is npx](../support/FAQ.md#what-is-npx) for more details.

package.json

@@ -20,11 +20,11 @@
     "Pierre Vanduynslager (https://twitter.com/@pvdlg_)"
   ],
   "dependencies": {
-    "@semantic-release/commit-analyzer": "^8.0.0",
-    "@semantic-release/error": "^2.2.0",
-    "@semantic-release/github": "^7.0.0",
-    "@semantic-release/npm": "^7.0.0",
-    "@semantic-release/release-notes-generator": "^9.0.0",
+    "@semantic-release/commit-analyzer": "^9.0.0-beta.3",
+    "@semantic-release/error": "^3.0.0-beta.1",
+    "@semantic-release/github": "^8.0.0-beta.1",
+    "@semantic-release/npm": "^8.0.0-beta.1",
+    "@semantic-release/release-notes-generator": "^10.0.0-beta.2",
     "aggregate-error": "^3.0.0",
     "cosmiconfig": "^7.0.0",
     "debug": "^4.0.0",
@@ -56,7 +56,7 @@
     "delay": "5.0.0",
     "dockerode": "3.3.0",
     "file-url": "3.0.0",
-    "fs-extra": "10.0.0",
+    "fs-extra": "9.1.0",
     "got": "11.8.2",
     "js-yaml": "4.1.0",
     "mockserver-client": "5.11.2",
@@ -70,7 +70,7 @@
     "xo": "0.29.1"
   },
   "engines": {
-    "node": ">=10.18"
+    "node": ">=14.17"
   },
   "files": [
     "bin",

test/helpers/config.yaml

@@ -0,0 +1,23 @@
+storage: /verdaccio/storage/data
+plugins: /verdaccio/plugins
+web:
+  title: Verdaccio
+auth:
+  htpasswd:
+    file: /verdaccio/storage/htpasswd
+packages:
+  '@*/*':
+    access: $all
+    publish: $authenticated
+    unpublish: $authenticated
+  '**':
+    access: $all
+    publish: $authenticated
+    unpublish: $authenticated
+server:
+  keepAliveTimeout: 60
+middlewares:
+  audit:
+    enabled: true
+logs:
+  - { type: stdout, format: pretty, level: http }

test/helpers/npm-registry.js

@@ -1,15 +1,13 @@
 const Docker = require('dockerode');
 const getStream = require('get-stream');
 const got = require('got');
+const path = require('path');
 const delay = require('delay');
 const pRetry = require('p-retry');
 
-const IMAGE = 'semanticrelease/npm-registry-docker:latest';
-const SERVER_PORT = 15986;
-const COUCHDB_PORT = 5984;
-const SERVER_HOST = 'localhost';
-const COUCHDB_USER = 'admin';
-const COUCHDB_PASSWORD = 'password';
+const IMAGE = 'verdaccio/verdaccio:4';
+const REGISTRY_PORT = 4873;
+const REGISTRY_HOST = 'localhost';
 const NPM_USERNAME = 'integration';
 const NPM_PASSWORD = 'suchsecure';
 const NPM_EMAIL = 'integration@test.com';
@@ -25,8 +23,8 @@ async function start() {
   container = await docker.createContainer({
     Tty: true,
     Image: IMAGE,
-    PortBindings: {[`${COUCHDB_PORT}/tcp`]: [{HostPort: `${SERVER_PORT}`}]},
-    Env: [`COUCHDB_USER=${COUCHDB_USER}`, `COUCHDB_PASSWORD=${COUCHDB_PASSWORD}`],
+    PortBindings: {[`${REGISTRY_PORT}/tcp`]: [{HostPort: `${REGISTRY_PORT}`}]},
+    Binds: [`${path.join(__dirname, 'config.yaml')}:/verdaccio/conf/config.yaml`],
   });
 
   await container.start();
@@ -34,7 +32,7 @@ async function start() {
 
   try {
     // Wait for the registry to be ready
-    await pRetry(() => got(`http://${SERVER_HOST}:${SERVER_PORT}/registry/_design/app`, {cache: false}), {
+    await pRetry(() => got(`http://${REGISTRY_HOST}:${REGISTRY_PORT}/`, {cache: false}), {
       retries: 7,
       minTimeout: 1000,
       factor: 2,
@@ -44,9 +42,7 @@ async function start() {
   }
 
   // Create user
-  await got(`http://${SERVER_HOST}:${SERVER_PORT}/_users/org.couchdb.user:${NPM_USERNAME}`, {
-    username: COUCHDB_USER,
-    password: COUCHDB_PASSWORD,
+  await got(`http://${REGISTRY_HOST}:${REGISTRY_PORT}/-/user/org.couchdb.user:${NPM_USERNAME}`, {
     method: 'PUT',
     json: {
       _id: `org.couchdb.user:${NPM_USERNAME}`,
@@ -59,7 +55,7 @@ async function start() {
   });
 }
 
-const url = `http://${SERVER_HOST}:${SERVER_PORT}/registry/_design/app/_rewrite/`;
+const url = `http://${REGISTRY_HOST}:${REGISTRY_PORT}/`;
 
 const authEnv = {
   npm_config_registry: url, // eslint-disable-line camelcase