feat(node-version): raised the minimum required version to v14.17 (#2132)

BREAKING CHANGE: the minimum required version of node is now v14.17
This commit is contained in:
Matt Travi 2021-09-17 15:05:32 -05:00 committed by GitHub
parent 1632e1adac
commit 66cc2b4c7f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
15 changed files with 986 additions and 2239 deletions

View File

@ -17,9 +17,8 @@ jobs:
strategy:
matrix:
node-version:
- 10.19.0
- 12
- 14
- 14.17
- 16
runs-on: ubuntu-latest

View File

@ -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.19 or higher](docs/support/FAQ.md#why-does-semantic-release-require-node-version--1019) 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

View File

@ -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"
}
}
```

View File

@ -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.19](../support/FAQ.md#why-does-semantic-release-require-node-version--1019).
**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 10.19 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: '10.19'
node-version: '14.17'
- name: Install dependencies
run: npm ci
- name: Release

View File

@ -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.19 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1019).
**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

View File

@ -10,9 +10,9 @@ 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.19 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1019).
**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.
@ -35,7 +35,7 @@ pipeline {
}
stage('Release') {
tools {
nodejs "node 10.19"
nodejs "node 14.17"
}
steps {
sh '''
@ -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"
}
}
```
```

View File

@ -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 10 and 12. 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:
- 10
- 12
- 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"
}
}
```

View File

@ -45,7 +45,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)
- Make sure your CI job executing the `semantic-release` command has access to [Node >= 10.19](#why-does-semantic-release-require-node-version--1019) 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.
@ -204,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.19?
## 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.19 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.

View File

@ -1,6 +1,6 @@
# Node Support Policy
We only support [Long-Term Support](https://github.com/nodejs/Release) versions of Node starting with [Node 10.19 (LTS)](https://nodejs.org/en/blog/release/v10.19.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.

View File

@ -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 Node version 10.19 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 10.19 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.19
### 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.19 or higher. This can either be a job used by your project to test on Node >= 10.19 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 10 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@10 -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 10.19 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 10.19 && npx semantic-release
$ nvm install 14.17 && npx semantic-release
```

View File

@ -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@17`). 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.

3101
package-lock.json generated

File diff suppressed because it is too large Load Diff

View File

@ -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",
"@semantic-release/error": "^3.0.0",
"@semantic-release/github": "^8.0.0",
"@semantic-release/npm": "^8.0.0",
"@semantic-release/release-notes-generator": "^10.0.0",
"aggregate-error": "^3.0.0",
"cosmiconfig": "^7.0.0",
"debug": "^4.0.0",
@ -70,7 +70,7 @@
"xo": "0.29.1"
},
"engines": {
"node": ">=10.19"
"node": ">=14.17"
},
"files": [
"bin",

23
test/helpers/config.yaml Normal file
View File

@ -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 }

View File

@ -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