Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(engines): fixed defined node version to account for the higher requirement from the npm plugin #2088

Merged
merged 9 commits into from Aug 25, 2021
Merged
6 changes: 3 additions & 3 deletions .github/workflows/test.yml
Expand Up @@ -17,7 +17,7 @@ jobs:
strategy:
matrix:
node-version:
- 10.18.0
- 10.19.0
- 12
- 14

Expand All @@ -32,8 +32,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

Expand All @@ -48,4 +46,6 @@ jobs:
with:
cache: npm
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to add the node version explicitly here

Suggested change
cache: npm
cache: npm
node-version:10.19.0

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i dont think this needs to change from what we had before. ls-engines doesn't do its comparison against the current execution context like we expected engine-strict to do. instead, it analyzes the effective engines range of the dependency tree and compares it against the project's declared engines range. it can do that in any version of node that can execute ls-engines. does this explanation address the reason you were expecting an explicit version to be declared for this job?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah got it! In that case I'd set node-version to 16. Otherwise we get the OS default node version that might change any time. I probably set this up myself without setting node-version explicitly, but I'm doing that now everywhere. But we can do that later, it's outside of the scope here

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, makes sense. since i like to keep a record of a preferred development node version in a .nvmrc file in the repo, i typically take care of this by referencing the value from that file in non-matrix jobs, like https://github.com/form8ion/project/blob/b05d76fa60e4c648efbaf98d8f68e69d0155da94/.github/workflows/node-ci.yml#L43

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'll plan to get the explicit v16 added to that job as part of our wip v16 branch

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nevermind, looks like you already have a PR open for this in #2092 👍🏼

- run: npm ci
- name: Ensure dependencies are compatible with the version of node
run: npx ls-engines@0.4
- run: npm run lint
2 changes: 1 addition & 1 deletion README.md
Expand Up @@ -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 [10.19 or higher](docs/support/FAQ.md#why-does-semantic-release-require-node-version--1019) installed in your Continuous Integration environment

## Documentation

Expand Down
6 changes: 3 additions & 3 deletions docs/recipes/github-actions.md
Expand Up @@ -10,11 +10,11 @@ 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 >= 10.19](../support/FAQ.md#why-does-semantic-release-require-node-version--1019).

### `.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 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.

```yaml
name: Release
Expand All @@ -34,7 +34,7 @@ jobs:
- name: Setup Node.js
uses: actions/setup-node@v1
with:
node-version: 12
node-version: '10.19'
- name: Install dependencies
run: npm ci
- name: Release
Expand Down
4 changes: 2 additions & 2 deletions 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 >= 10.18 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1018).
**Note**: The publish pipeline must run a [Node >= 10.19 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1019).

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

Expand Down Expand Up @@ -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

Expand Down
10 changes: 5 additions & 5 deletions docs/recipes/jenkins-ci.md
Expand Up @@ -10,7 +10,7 @@ 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 >= 10.19 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1019).

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.

Expand All @@ -19,7 +19,7 @@ The`semantic-release` execution command varies depending if you are using a [loc
```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')
}
Expand All @@ -35,14 +35,14 @@ pipeline {
}
stage('Release') {
tools {
nodejs "node 10.18"
nodejs "node 10.19"
}
steps {
sh '''
# Run optional required steps before releasing
npx semantic-release
'''
}
}
}
}
}
Expand All @@ -58,4 +58,4 @@ A `package.json` is required only for [local](../usage/installation.md#local-ins
"semantic-release": "^15.0.0"
}
}
```
```
6 changes: 3 additions & 3 deletions docs/recipes/travis.md
Expand Up @@ -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 10 and 12. 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).

Expand All @@ -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
- 10
- 12

jobs:
include:
Expand Down
38 changes: 4 additions & 34 deletions docs/support/FAQ.md
Expand Up @@ -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 >= 10.19](#why-does-semantic-release-require-node-version--1019) 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 @@ -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 >= 10.19?

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

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

Expand Down
2 changes: 1 addition & 1 deletion 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 10.19 (LTS)](https://nodejs.org/en/blog/release/v10.19.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.

Expand Down
16 changes: 8 additions & 8 deletions docs/support/node-version.md
@@ -1,35 +1,35 @@
# 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 Node version 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 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 10.19 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 >= 10.19

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

See [CI configuration](../usage/ci-configuration.md) and [CI configuration recipes](../recipes/README.md#ci-configurations) for more details.

## Alternative solutions

### 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 10 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@10 -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 10.19 before running the `semantic-release` command.

```bash
$ nvm install 8 && npx semantic-release
$ nvm install 10.19 && npx semantic-release
```
2 changes: 1 addition & 1 deletion docs/usage/installation.md
Expand Up @@ -24,6 +24,6 @@ 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@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**: `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.
19 changes: 9 additions & 10 deletions package-lock.json

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

4 changes: 2 additions & 2 deletions package.json
Expand Up @@ -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",
Expand All @@ -70,7 +70,7 @@
"xo": "0.29.1"
},
"engines": {
"node": ">=10.18"
"node": ">=10.19"
},
"files": [
"bin",
Expand Down