IMPORTANT: No additional bug fixes or documentation updates will be released for this version. For the latest information, see the current release documentation.

« Considerations for basepath Sharing saved objects »

› › ›

Upgrading Node.js

edit

Upgrading Node.js

edit

Kibana requires a specific Node.js version to run. When running Kibana from source, you must have this version installed locally.

Step 1: Generate custom Node.js builds

edit

Before making a PR to upgrade Node.js, we must first generate the required custom Node.js builds matching the desired Node.js version.

Step 2: Create PR to upgrade Node.js

edit

The required version of Node.js is listed in several different files throughout the Kibana source code. These files must be updated when upgrading Node.js:

.ci/Dockerfile - The version is specified in the NODE_VERSION constant. This is used to pull the relevant image from Docker Hub. Note that Docker Hub can take 24+ hours to be updated with the new images after a new release of Node.js, so if you’re upgrading Node.js in Kibana just after the official Node.js release, you have to check if the new images are present on Docker Hub. If they are not, and the update is urgent, you can skip this file and update it later once Docker Hub has been updated.
.node-version
.nvmrc
package.json - The version is specified in the engines.node field (if possible, also upgrade @types/node to match the new version, both under devDependencies and resolutions).
WORKSPACE.bazel - The version is specified in the node_version property. Besides this property, the list of files under node_repositories must be updated along with their respective SHA256 hashes. These can be found in the SHASUMS256.txt file inside the public kibana-custom-node-artifacts GCP bucket. Example for Node.js v18.19.1: kibana-custom-node-artifacts/node-glibc-217/dist/v18.19.1/SHASUMS256.txt

See PR #128123 for an example of how the Node.js version has been upgraded previously.

Considerations with major Node.js upgrades

edit

When upgrading to a new major version of Node.js, the following extra steps must be performed:

Compare the new Node.js versions list of supported platforms with the Kibana Support Matrix. As an example, here’s the Node.js 18 supported platform list. You can change which Node.js major version to view, by changing the selected branch. If Node.js has dropped support for platform still supported by Kibana, appropriate steps must be taken as soon as possible to deprecate support for this platform. This way support for it can be dropped before the currently used major version of Node.js reaches End-of-Life.

Custom builds of Node.js

edit

Due to Node.js 16 coming to an early End-of-Life and Node.js 18 no longer supporting the same platforms that Kibana supports (most notably CentOS7/RHEL7), we cannot bundle the official Node.js binaries with the Linux distributable of Kibana. To keep support for these older platforms, we’re bundling the Linux distributable of Kibana with a custom build of Node.js with extended backwards compatibility. The only difference between the offical Node.js build and our custom build, is the version of glibc that it’s compiled against.

How to start a new build

edit

To generate a new custom Node.js build, start a new build on our dedicated Buildkite pipeline (requires Elastic employee permissions). Give it a clear name (e.g. Node 18.19.1) and remember so set the custom OVERRIDE_TARGET_VERSION environment variable to the desired Node.js version - e.g. OVERRIDE_TARGET_VERSION=18.19.1. You find the "Environment Variables" field by expanding "Options >" in the "New Build" dialog.

Backporting

edit

The following rules are not set in stone. Use best judgement when backporting.

Node.js patch upgrades

edit

Typically, you want to backport Node.js patch upgrades to all supported release branches that run the same major Node.js version (which currently is all of them, but this might change in the future):

If the current release is 8.1.x, the main PR should target main and be backported to 7.17 and 8.1 (GitHub tag example: backport:all-open).

Node.js minor upgrades

edit

Typically, you want to backport Node.js minor upgrades to the previous major Kibana release branch (if it runs the same major Node.js version):

If the current release is 8.1.x, the main PR should target main and be backported to 7.17, while leaving the 8.1 branch as-is (GitHub tag example: auto-backport + v7.17.13).

Node.js major upgrades

edit

Typically, you want to backport Node.js major upgrades to the previous major Kibana release branch:

If the current release is 8.1.x, the main PR should target main and be backported to 7.17, while leaving the 8.1 branch as-is (GitHub tag example: auto-backport + v7.17.13).

Upgrading installed Node.js version

edit

The following instructions expect that nvm is used to manage locally installed Node.js versions.

Run the following to install the new Node.js version. Replace <version> with the desired Node.js version:

nvm install <version>

To get the same global npm modules installed with the new version of Node.js as is currently installed, use the --reinstall-packages-from command-line argument (optionally replace 16 with the desired source version):

nvm install <version> --reinstall-packages-from=16

If needed, uninstall the old version of Node.js by running the following. Replace <old-version> with the full version number of the version that should be uninstalled:

nvm uninstall <old-version>

Optionally, tell nvm to always use the "highest" installed Node.js 16 version. Replace 16 if a different major version is desired:

nvm alias default 16

Alternatively, include the full version number at the end to specify a specific default version.

« Considerations for basepath Sharing saved objects »