[build] update node versioning for testing and publishing - #17866

• Add a JavaScript CI workflow running Bazel build and unit tests on oldest/newest supported Node.
• Switch CI/release Node selection to write .nvmrc, letting rules_nodejs pick the hermetic
 toolchain.
• Raise JS minimum Node to 22 and document an EOL-based Node support policy; pin release to Node
 24.14.1.

graph TD
  A["GitHub CI (ci.yml)"] --> B["CI - JavaScript (ci-javascript.yml)"] --> C["Reusable Bazel job (bazel.yml)"] --> D[".nvmrc"] --> E["rules_nodejs toolchain"] --> F["Bazel JS build/tests"]
  G["Release workflow (release.yml)"] --> C
  subgraph Legend
    direction LR
    _wf["Workflow"] ~~~ _cfg["Config file"] ~~~ _tc["Toolchain"]
  end

Loading

The following are alternative approaches to this PR:

1. Continue using actions/setup-node for publish/test

• ➕ Simple and familiar GitHub Actions pattern
• ➕ Avoids .nvmrc file writes in workflows
• ➖ Does not affect Bazel hermetic toolchain unless explicitly wired through, risking version drift
• ➖ Harder to guarantee npm 11 for the actual bazel-executed publish step

2. Pin Node versions directly in MODULE.bazel (no `.nvmrc`)

• ➕ Single source of truth inside Bazel config
• ➕ No CI workflow mutation of files
• ➖ Harder to vary Node per CI job (matrix) without additional Bazel plumbing
• ➖ Less consistent with existing repo pattern of version files per language/toolchain

3. Use a tool-versions manager (e.g., asdf) for Node pinning

• ➕ Unified version management across languages for developer workstations
• ➖ Still doesn’t inherently control Bazel’s hermetic toolchain selection
• ➖ Adds another tool/dependency surface area for contributors and CI

Recommendation: The chosen approach (drive rules_nodejs via .nvmrc and have CI write it per job) is the best fit because it aligns the actual build/test/publish runtime with Bazel’s hermetic toolchain, while still enabling a Node version matrix in CI and ensuring npm 11 for trusted publishing. The main review focus should be on ensuring no other workflows depend on system-installed Node and that the .nvmrc override is scoped only to jobs that need it.

Enhancement (1) +1 / -1

package.jsonBump 'engines.node' minimum to >=22 +1/-1

Bump 'engines.node' minimum to >=22

• Raises the Node engine constraint from >=20 to >=22 to match the documented support policy and CI expectations.

javascript/selenium-webdriver/package.json

Bug fix (1) +1 / -1

release.ymlPin JS release Node to 24.14.1 for npm 11 trusted publishing +1/-1

Pin JS release Node to 24.14.1 for npm 11 trusted publishing

• Changes the JavaScript publish job to request an explicit Node version (24.14.1) rather than a major-only '24'. This makes the hermetic toolchain provide a sufficiently new npm 11 for OIDC trusted publishing.

.github/workflows/release.yml

Documentation (1) +13 / -10

README.mdDocument Node support policy and raise minimum to Node 22 +13/-10

Document Node support policy and raise minimum to Node 22

• Updates the stated minimum Node requirement from 20 to 22 and rewrites the support policy to be based on upstream active support through EOL. Adds a concise table of supported major versions and clarifies CI coverage expectations.

javascript/selenium-webdriver/README.md

Other (5) +51 / -8

bazel.ymlSwitch Node selection from setup-node to '.nvmrc' override +3/-5

Switch Node selection from setup-node to '.nvmrc' override

• Replaces 'actions/setup-node' with a step that writes the requested Node version into '.nvmrc'. This ensures Bazel’s rules_nodejs toolchain (not the runner’s system Node) determines the Node/npm version used by build/test/publish.

.github/workflows/bazel.yml

ci-javascript.ymlAdd JS CI workflow with Node oldest/newest test matrix +36/-0

Add JS CI workflow with Node oldest/newest test matrix

• Introduces a JavaScript-specific workflow that builds the selenium-webdriver target and runs unit tests on a Node version matrix (oldest and newest supported versions available in rules_nodejs). Uses the shared Bazel workflow and passes a pinned Node version per matrix entry.

.github/workflows/ci-javascript.yml

ci.ymlWire JavaScript into top-level CI orchestration +10/-2

Wire JavaScript into top-level CI orchestration

• Adds '//javascript/...' to the target discovery set and includes a new 'javascript' job that calls the JS CI workflow when JS targets are present. Updates the CI success aggregator to include the new job.

.github/workflows/ci.yml

.nvmrcAdd repository Node pin for rules_nodejs toolchain +1/-0

Add repository Node pin for rules_nodejs toolchain

• Adds a default '.nvmrc' value (22.22.0) used by the Bazel Node toolchain when CI does not override it. Establishes a shared version file that workflows can update per job.

.nvmrc

MODULE.bazelRead Node toolchain version from '.nvmrc' +1/-1

Read Node toolchain version from '.nvmrc'

• Updates rules_nodejs toolchain configuration to use 'node_version_from_nvmrc = "//:.nvmrc"' instead of a hardcoded Node version. This enables CI and release jobs to control the hermetic Node version by setting '.nvmrc'.

MODULE.bazel

Description

The PR raises the minimum supported Node version to 22, which removes the ability for users on Node
20 to use selenium-webdriver without providing a deprecation notice and an explicit alternative
path for those users. This can cause unexpected breakage for downstream consumers still pinned to
Node 20.

Code

javascript/selenium-webdriver/package.json[R22-24]

  "engines": {
-    "node": ">= 20.0.0"
+    "node": ">= 22.0.0"
  },

Evidence

PR changes the published engine constraint to node >= 22.0.0 and updates the README to state
Requires Node.js >= 22, which effectively removes support for Node 20; no deprecation period or
alternative (e.g., “pin to last version supporting Node 20”) is provided alongside this removal.

AGENTS.md: Deprecate Public Functionality Before Removal
javascript/selenium-webdriver/package.json[22-24]
javascript/selenium-webdriver/README.md[6-79]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR changes the public runtime requirement from Node 20+ to Node 22+, but does not include a deprecation notice (ahead of removal) or clear guidance for users who cannot yet upgrade Node.

## Issue Context
Compliance requires public functionality to be deprecated (with an alternative) before it is removed. For a runtime support drop, the “alternative” is typically: upgrade Node, or pin to the last `selenium-webdriver` version that supports the older Node.

## Fix Focus Areas
- javascript/selenium-webdriver/README.md[6-9]
- javascript/selenium-webdriver/README.md[64-80]
- javascript/selenium-webdriver/package.json[22-24]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools