simon/semantic-release
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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

Browse Source 
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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
.github/workflows/test.yml vendored
View File

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

2
README.md
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) - 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) - 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 - 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 ## Documentation

4
docs/recipes/circleci-workflows.md
View File

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

7
docs/recipes/github-actions.md
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. [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 ### `.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 ```yaml
name: Release name: Release
@ -34,7 +35,7 @@ jobs:
- name: Setup Node.js - name: Setup Node.js
uses: actions/setup-node@v1 uses: actions/setup-node@v1
with: with:
node-version: '10.19' node-version: '14.17'
- name: Install dependencies - name: Install dependencies
run: npm ci run: npm ci
- name: Release - name: Release

2
docs/recipes/gitlab-ci.md
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. 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 ### `.gitlab-ci.yml` configuration for Node projects

8
docs/recipes/jenkins-ci.md
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 ### `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. 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') { stage('Release') {
tools { tools {
nodejs "node 10.19" nodejs "node 14.17"
} }
steps { steps {
sh ''' sh '''
@ -55,7 +55,7 @@ A `package.json` is required only for [local](../usage/installation.md#local-ins
```json ```json
{ {
"devDependencies": { "devDependencies": {
"semantic-release": "^15.0.0" "semantic-release": "^18.0.0"
} }
} }
``` ```

8
docs/recipes/travis.md
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 ### `.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). 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 language: node_js
node_js: node_js:
- 10 - 14
- 12 - 16
jobs: jobs:
include: include:
@ -48,7 +48,7 @@ A `package.json` is required only for [local](../usage/installation.md#local-ins
```json ```json
{ {
"devDependencies": { "devDependencies": {
"semantic-release": "^15.0.0" "semantic-release": "^18.0.0"
} }
} }
``` ```

6
docs/support/FAQ.md
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: 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 - 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 [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. 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). 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. See [Node version requirement](./node-version.md#node-version-requirement) for more details and solutions.

2
docs/support/node-support-policy.md
View File

@ -1,6 +1,6 @@
# Node Support Policy # 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. 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.

18
docs/support/node-version.md
View File

@ -1,16 +1,17 @@
# Node version requirement # 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. See our [Node Support Policy](node-support-policy.md) for our long-term promise regarding Node version support.
## Recommended solution ## 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. 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` ### 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 ```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. **Note:**: See [What is npx](./FAQ.md#what-is-npx) for more details.
### Use `nvm` ### 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 ```bash
$ nvm install 10.19 && npx semantic-release $ nvm install 14.17 && npx semantic-release
``` ```

3
docs/usage/installation.md
View File

@ -24,6 +24,7 @@ For other type of projects we recommend installing **semantic-release** directly
$ npx semantic-release $ 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. **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.

3165
package-lock.json generated
View File

File diff suppressed because it is too large Load Diff

12
package.json
View File

@ -20,11 +20,11 @@
"Pierre Vanduynslager (https://twitter.com/@pvdlg_)" "Pierre Vanduynslager (https://twitter.com/@pvdlg_)"
], ],
"dependencies": { "dependencies": {
"@semantic-release/commit-analyzer": "^8.0.0", "@semantic-release/commit-analyzer": "^9.0.0",
"@semantic-release/error": "^2.2.0", "@semantic-release/error": "^3.0.0",
"@semantic-release/github": "^7.0.0", "@semantic-release/github": "^8.0.0",
"@semantic-release/npm": "^7.0.0", "@semantic-release/npm": "^8.0.0",
"@semantic-release/release-notes-generator": "^9.0.0", "@semantic-release/release-notes-generator": "^10.0.0",
"aggregate-error": "^3.0.0", "aggregate-error": "^3.0.0",
"cosmiconfig": "^7.0.0", "cosmiconfig": "^7.0.0",
"debug": "^4.0.0", "debug": "^4.0.0",
@ -70,7 +70,7 @@
"xo": "0.29.1" "xo": "0.29.1"
}, },
"engines": { "engines": {
"node": ">=10.19" "node": ">=14.17"
}, },
"files": [ "files": [
"bin", "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 }

22
test/helpers/npm-registry.js
View File

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