Skip to content

Commit

Permalink
feat: require Node.js >=10.13
Browse files Browse the repository at this point in the history
BREAKING CHANGE: Require Node.js >= 10.13
  • Loading branch information
pvdlg committed Dec 5, 2019
1 parent 916c268 commit 0716a45
Show file tree
Hide file tree
Showing 12 changed files with 23 additions and 21 deletions.
3 changes: 1 addition & 2 deletions .travis.yml
Expand Up @@ -5,8 +5,7 @@ services:

node_js:
- 12
- 10
- 8.16
- 10.13

# Trigger a push build on release and greenkeeper branches + PRs build on every branches
# Avoid double build on PRs (See https://github.com/travis-ci/travis-ci/issues/1147)
Expand Down
2 changes: 1 addition & 1 deletion bin/semantic-release.js
Expand Up @@ -35,7 +35,7 @@ execa('git', ['--version'])
process.exit(1);
});

// Node 8+ from this point on
// Node 10+ from this point on
require('../cli')()
.then(exitCode => {
process.exitCode = exitCode;
Expand Down
2 changes: 1 addition & 1 deletion docs/recipes/github-actions.md
Expand Up @@ -10,7 +10,7 @@ In this example an [`NPM_TOKEN`](https://docs.npmjs.com/creating-and-viewing-aut

[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 >= 8.16](../support/FAQ.md#why-does-semantic-release-require-node-version--816).
**Note**: The publish pipeline must run on [Node version >= 10.13](../support/FAQ.md#why-does-semantic-release-require-node-version--1013).

### `.github/workflows/release.yml` configuration for Node projects

Expand Down
2 changes: 1 addition & 1 deletion docs/recipes/gitlab-ci.md
Expand Up @@ -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 >= 8.16 version](../support/FAQ.md#why-does-semantic-release-require-node-version--816).
**Note**: The publish pipeline must run a [Node >= 10.13 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1013).

### `.gitlab-ci.yml` configuration for Node projects

Expand Down
10 changes: 5 additions & 5 deletions docs/support/FAQ.md
Expand Up @@ -38,7 +38,7 @@ Yes with the [dry-run options](../usage/configuration.md#dryrun) which prints to

## 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 >= 8.16](#why-does-semantic-release-require-node-version--816) and specifies it in its `package.json`s [`engines`](https://docs.npmjs.com/files/package.json#engines) key.
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.13](#why-does-semantic-release-require-node-version--1013) 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:

Expand All @@ -48,7 +48,7 @@ $ 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 >= 8.16.
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.13.

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:

Expand All @@ -73,7 +73,7 @@ Yes, **semantic-release** is a Node CLI application but it can be used to publis
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 >= 8.16](#why-does-semantic-release-require-node-version--816) to execute the `semantic-release` command
- Make sure your CI job executing the `semantic-release` command has access to [Node >= 10.13](#why-does-semantic-release-require-node-version--1013) to execute the `semantic-release` command

See the [CI configuration recipes](../recipes/README.md#ci-configurations) for more details on specific CI environments.

Expand Down Expand Up @@ -232,9 +232,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 >= 8.16?
## Why does semantic-release require Node version >= 10.13?

**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 8.16 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 10.13 or higher**.

See [Node version requirement](./node-version.md#node-version-requirement) for more details and solutions.

Expand Down
6 changes: 3 additions & 3 deletions docs/support/node-version.md
@@ -1,16 +1,16 @@
# 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 8.16 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 10 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.

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 >= 8.16
### Run at least one CI job with Node >= 10.13

The recommended approach is to run the `semantic-release` command from a CI job running on Node 8.16 or higher. This can either be a job used by your project to test on Node >= 8.16 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 10.13 or higher. This can either be a job used by your project to test on Node >= 10.13 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.

Expand Down
2 changes: 1 addition & 1 deletion lib/branches/index.js
Expand Up @@ -50,7 +50,7 @@ module.exports = async (repositoryUrl, ciBranch, context) => {
const duplicates = [...branches]
.map(branch => branch.name)
.sort()
.filter((val, idx, arr) => arr[idx] === arr[idx + 1] && arr[idx] !== arr[idx - 1]);
.filter((_, idx, arr) => arr[idx] === arr[idx + 1] && arr[idx] !== arr[idx - 1]);

if (duplicates.length > 0) {
errors.push(getError('EDUPLICATEBRANCHES', {duplicates}));
Expand Down
3 changes: 2 additions & 1 deletion lib/get-git-auth-url.js
Expand Up @@ -47,7 +47,8 @@ module.exports = async ({cwd, env, branch, options: {repositoryUrl}}) => {

if (gitCredentials) {
// If credentials are set via environment variables, convert the URL to http/https and add basic auth, otherwise return `repositoryUrl` as is
const [match, auth, host, path] = /^(?!.+:\/\/)(?:(.*)@)?(.*?):(.*)$/.exec(repositoryUrl) || [];
const [match, auth, host, path] =
/^(?!.+:\/\/)(?:(?<auth>.*)@)?(?<host>.*?):(?<path>.*)$/.exec(repositoryUrl) || [];
const {port, hostname, ...parsed} = parse(
match ? `ssh://${auth ? `${auth}@` : ''}${host}/${path}` : repositoryUrl
);
Expand Down
4 changes: 2 additions & 2 deletions lib/git.js
Expand Up @@ -65,7 +65,7 @@ async function getCommits(from, to, execaOpts) {
async function getBranches(repositoryUrl, execaOpts) {
return (await execa('git', ['ls-remote', '--heads', repositoryUrl], execaOpts)).stdout
.split('\n')
.map(branch => branch.match(/^.+refs\/heads\/(.+)$/)[1])
.map(branch => branch.match(/^.+refs\/heads\/(?<branch>.+)$/)[1])
.filter(Boolean);
}

Expand Down Expand Up @@ -312,7 +312,7 @@ async function verifyBranchName(branch, execaOpts) {
async function isBranchUpToDate(repositoryUrl, branch, execaOpts) {
const {stdout: remoteHead} = await execa('git', ['ls-remote', '--heads', repositoryUrl, branch], execaOpts);
try {
return await isRefInHistory(remoteHead.match(/^(\w+)?/)[1], branch, execaOpts);
return await isRefInHistory(remoteHead.match(/^(?<ref>\w+)?/)[1], branch, execaOpts);
} catch (error) {
debug(error);
}
Expand Down
6 changes: 4 additions & 2 deletions lib/utils.js
Expand Up @@ -31,11 +31,13 @@ function isMaintenanceRange(range) {
}

function getUpperBound(range) {
return semver.valid(range) ? range : ((semver.validRange(range) || '').match(/<(\d+\.\d+\.\d+)$/) || [])[1];
return semver.valid(range)
? range
: ((semver.validRange(range) || '').match(/<(?<upperBound>\d+\.\d+\.\d+)$/) || [])[1];
}

function getLowerBound(range) {
return ((semver.validRange(range) || '').match(/(\d+\.\d+\.\d+)/) || [])[1];
return ((semver.validRange(range) || '').match(/(?<lowerBound>\d+\.\d+\.\d+)/) || [])[1];
}

function highest(version1, version2) {
Expand Down
2 changes: 1 addition & 1 deletion package.json
Expand Up @@ -72,7 +72,7 @@
"xo": "^0.25.0"
},
"engines": {
"node": ">=8.16"
"node": ">=10.13"
},
"files": [
"bin",
Expand Down
2 changes: 1 addition & 1 deletion test/helpers/git-utils.js
Expand Up @@ -213,7 +213,7 @@ export async function gitRemoteTagHead(repositoryUrl, tagName, execaOpts) {
return (await execa('git', ['ls-remote', '--tags', repositoryUrl, tagName], execaOpts)).stdout
.split('\n')
.filter(tag => Boolean(tag))
.map(tag => tag.match(/^(\S+)/)[1])[0];
.map(tag => tag.match(/^(?<tag>\S+)/)[1])[0];
}

/**
Expand Down

0 comments on commit 0716a45

Please sign in to comment.