Skip to content

chore: bump Node.js minimum to 25#961

Merged
JohnMcLear merged 1 commit into
mainfrom
chore/node-25
May 15, 2026
Merged

chore: bump Node.js minimum to 25#961
JohnMcLear merged 1 commit into
mainfrom
chore/node-25

Conversation

@JohnMcLear
Copy link
Copy Markdown
Member

Summary

  • package.json engines.node: >=22.0.0>=25.0.0
  • CI (ci.yml, npmpublish.yml): node-version: 22.22.025

Companion to ether/etherpad#7749, which moves Etherpad's runtime floor to Node 25. ueberDB has historically tracked Etherpad's minimum and tests on the same Node version, so bumping here keeps the library and its primary consumer in lock-step.

Tradeoff to confirm

External consumers (third-party projects that depend on ueberdb2) still on Node 18/20/22 will no longer be able to install the next 6.1.x release. The previous engine policy (>=22.0.0, relaxed from >=22.22.0 in 784cfcf) was conservative so consumers on widely-deployed Node 22 could keep installing. Bumping to 25 makes ueberDB depend on a non-LTS Current release, so anyone not on Node 25 needs to pin to a 6.0.x line.

This PR is the "see what happens" experiment — green CI here verifies that the library itself works on Node 25; the policy decision (do we actually want to require 25 in the published package) is separate.

Test plan

  • Lint, ts-check, build green on Node 25 (ci.yml).
  • Full DB driver matrix green on Node 25 (npmpublish.yml test matrix on push).
  • Decide: do we ship this as 6.1.0, or keep engines at >=22.0.0 and let consumers self-select their runtime?

🤖 Generated with Claude Code

ueberDB has historically tracked Etherpad's Node floor. With Etherpad
now moving to require Node.js >= 25 (ether/etherpad#7749), bump
ueberDB's `engines.node` and CI runner Node version to match. This
keeps the library in lock-step with its primary consumer so plugin
authors and Etherpad installs don't end up on diverging runtimes.

External consumers still on Node 22/24 should pin to a 6.0.x release;
this commit prepares 6.1.x for the cutover.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@qodo-code-review
Copy link
Copy Markdown

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

@qodo-free-for-open-source-projects
Copy link
Copy Markdown

Review Summary by Qodo

Bump Node.js minimum requirement to 25.0.0

✨ Enhancement

Grey Divider

Walkthroughs

Description
• Bump Node.js minimum requirement from 22.0.0 to 25.0.0
• Update CI workflows to test on Node.js 25
• Align ueberDB runtime with Etherpad's Node floor
• Prepare 6.1.x release for Node 25 cutover
Diagram
flowchart LR
  A["Node 22.0.0"] -->|upgrade| B["Node 25.0.0"]
  B -->|applied to| C["package.json engines"]
  B -->|applied to| D["CI workflows"]
  C -->|affects| E["6.1.x releases"]
  D -->|tests on| F["Node 25 runtime"]
Loading

Grey Divider

File Changes

1. package.json ⚙️ Configuration changes +1/-1

Update Node.js engine requirement to 25

• Update engines.node from >=22.0.0 to >=25.0.0
• Enforces Node.js 25 as minimum for package installation
• Aligns with Etherpad's runtime floor requirement

package.json


2. .github/workflows/ci.yml ⚙️ Configuration changes +1/-1

Update CI build job to Node.js 25

• Update Node.js version from 22.22.0 to 25 in build job
• Ensures linting, type-checking, and build validation on Node 25

.github/workflows/ci.yml


3. .github/workflows/npmpublish.yml ⚙️ Configuration changes +2/-2

Update npm publish workflow to Node.js 25

• Update Node.js version from 22.22.0 to 25 in test job
• Update Node.js version from 22.22.0 to 25 in publish job
• Ensures full DB driver matrix testing on Node 25
• Validates package publication on Node 25

.github/workflows/npmpublish.yml


Grey Divider

Qodo Logo

@qodo-free-for-open-source-projects
Copy link
Copy Markdown

qodo-free-for-open-source-projects Bot commented May 15, 2026

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0)

Grey Divider


Remediation recommended

1. Unpinned CI Node version 🐞 Bug ☼ Reliability
Description
The workflows set actions/setup-node to node-version: 25, which will float to the latest 25.x
over time and can cause non-reproducible CI/publish results or unexpected breakage when a new 25.x
ships. This regresses determinism compared to the previously pinned patch version.
Code

.github/workflows/ci.yml[R20-23]

      - name: Setup Node.js
        uses: actions/setup-node@v6
        with:
-          node-version: 22.22.0
+          node-version: 25
Evidence
The CI and publish workflows explicitly request a floating major version (25) rather than a pinned
patch release; this will change over time as new 25.x versions are released.

.github/workflows/ci.yml[20-24]
.github/workflows/npmpublish.yml[23-26]
.github/workflows/npmpublish.yml[64-67]

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

### Issue description
GitHub Actions is configured with `node-version: 25`, which is a floating selector that will resolve to the latest available 25.x at runtime. This makes CI and publish behavior drift over time.

### Issue Context
The PR is bumping the minimum Node version; CI can still remain deterministic by pinning to a specific `25.x.y` (or by using a version file).

### Fix Focus Areas
- .github/workflows/ci.yml[20-23]
- .github/workflows/npmpublish.yml[23-26]
- .github/workflows/npmpublish.yml[64-67]

### Suggested fix
- Replace `node-version: 25` with a specific patch version (e.g., `25.x.y`), or
- Introduce a repo-wide version file (e.g. `.nvmrc`) and switch to `node-version-file`, then reference it from all workflows.

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



Advisory comments

2. Legacy Node version mismatch 🐞 Bug ⚙ Maintainability
Description
package.json now declares engines.node: >=25.0.0, but the repo still includes a .travis.yml
configured to run Node 14, which contradicts the supported runtime floor and can mislead or break
any Travis-based checks still in use.
Code

package.json[R157-159]

  "engines": {
-    "node": ">=22.0.0"
+    "node": ">=25.0.0"
  }
Evidence
The Node engine floor was raised to 25+, while the Travis configuration still specifies Node 14,
creating an explicit version-policy contradiction within the repository.

package.json[157-159]
.travis.yml[1-5]

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 repo’s declared Node engine floor is now `>=25.0.0`, but `.travis.yml` still targets Node 14. This is inconsistent and can confuse contributors/automation.

### Issue Context
Even if Travis CI is not actively used, keeping stale CI configs around increases maintenance burden and risk of accidental use.

### Fix Focus Areas
- package.json[157-159]
- .travis.yml[1-5]

### Suggested fix
- If Travis CI is still used: update `.travis.yml` to a supported Node version (>=25).
- If not used: remove `.travis.yml` to avoid confusion and accidental execution.

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


Grey Divider

Qodo Logo

@JohnMcLear JohnMcLear merged commit e11fda3 into main May 15, 2026
14 checks passed
@JohnMcLear JohnMcLear deleted the chore/node-25 branch May 15, 2026 09:40
JohnMcLear added a commit that referenced this pull request May 16, 2026
Etherpad has settled back on Node 24 as its minimum supported runtime
(ether/etherpad#7781), so ueberDB's recent bump to >=25 (#961) is now
ahead of its primary consumer. Lower `engines.node` and the CI runner
back to 24 to keep the library in lock-step.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant