Fix: relax Node engine from >=22.22.0 to >=18.0.0

[JohnMcLear]

The engine requirement was set to >=22.22.0 (an unreleased Node version). CI tests pass on Node 20, and Etherpad supports Node >=18.

Found by Qodo review on ether/etherpad#7516.

🤖 Generated with Claude Code

[qodo-free-for-open-source-projects]

Review Summary by Qodo

Relax Node engine requirement to >=18.0.0

🐞 Bug fix

Walkthroughs

Description

• Relax Node engine requirement from unreleased 22.22.0 to 18.0.0
• Aligns with actual CI testing on Node 20 and documented support
• Fixes overly restrictive version constraint in package.json

Diagram

flowchart LR
  A["package.json<br/>Node engine: >=22.22.0"] -- "Update to supported version" --> B["package.json<br/>Node engine: >=18.0.0"]

Loading

File Changes

1. package.json 🐞 Bug fix +1/-1

Update Node engine requirement to 18.0.0

• Changed Node engine requirement from >=22.22.0 to >=18.0.0
• Aligns with actual CI test coverage on Node 20
• Removes constraint on unreleased Node version

package.json

---

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (2)   📘 Rule violations (0)   📎 Requirement gaps (0)

🐞\ ☼ Reliability (1) ⚙ Maintainability (1)

1. CI tests wrong Node 🐞 ☼

Description

The PR relaxes the supported Node version to ">=18.0.0", but CI is still pinned to Node 22.22.0, so
the declared support range is not validated and the workflow may fail or produce artifacts untested
on the supported versions.

Code

package.json[143]

+    "node": ">=18.0.0"

Evidence

package.json now declares support for Node >=18, but the CI workflow explicitly configures Node
22.22.0, creating an inconsistency between the published support policy and what CI actually runs.

package.json[142-144]
.github/workflows/ci.yml[15-27]

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 CI workflow is pinned to a Node version that does not reflect the package's declared engine range after this PR.

### Issue Context
`package.json` now declares `engines.node: ">=18.0.0"`, but `.github/workflows/ci.yml` still runs CI on Node `22.22.0`.

### Fix Focus Areas
- package.json[142-144]
- .github/workflows/ci.yml[15-27]

### Suggested fix
- Update `.github/workflows/ci.yml` to test on supported versions (at minimum Node 18, and optionally also Node 20) via a matrix, or pin to an appropriate LTS version consistent with the engine policy.

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

---

2. Engine misstates backend support 🐞 ⚙

Description

Lowering engines.node to ">=18.0.0" implies all bundled backends work on Node 18.0, but the mssql
and elasticsearch backends rely on optional drivers that declare higher Node engine requirements
(>=18.17 and >=20), creating engine mismatches for those backends under Node 18.0.x.

Code

package.json[143]

+    "node": ">=18.0.0"

Evidence

The package includes mssql and elasticsearch backends (loaded dynamically) and declares their
drivers as optional peerDependencies, but the lockfile shows these driver dependency chains require
newer Node versions than 18.0.0.

package.json[31-56]
index.ts[24-162]
databases/mssql_db.ts[23-26]
pnpm-lock.yaml[113-162]
pnpm-lock.yaml[191-198]
pnpm-lock.yaml[2069-2072]
package.json[142-144]

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 package engine is relaxed to `>=18.0.0`, but some supported optional backends (notably `mssql` and `elasticsearch`) depend on optional drivers whose dependency trees require newer Node versions, which can surprise users when they select those backends on older Node 18 releases.

### Issue Context
- `DatabaseType` supports `mssql` and `elasticsearch` and loads them dynamically.
- The corresponding drivers are declared as optional peerDependencies.
- The lockfile shows Node engine requirements >=20 for parts of the dependency chain (e.g., `@elastic/transport`) and >=18.17 for `tedious`.

### Fix Focus Areas
- package.json[31-56]
- package.json[142-144]
- index.ts[24-162]
- pnpm-lock.yaml[113-162]
- pnpm-lock.yaml[191-198]
- pnpm-lock.yaml[2069-2072]

### Suggested fix options
Choose one:
1) If you intend to support all listed backends under the main package engine, raise `engines.node` to match the highest required Node version among the supported backends.
2) If you intend to keep core support at Node 18, add clear documentation and/or add an explicit runtime guard in `initDB()` for `mssql`/`elasticsearch` to throw a friendly error when `process.versions.node` is below the backend's minimum supported Node version.

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

---

ⓘ The new review experience is currently in Beta. Learn more

[qodo-free-for-open-source-projects]

1. Ci tests wrong node 🐞 Bug ☼ Reliability

The PR relaxes the supported Node version to ">=18.0.0", but CI is still pinned to Node 22.22.0, so
the declared support range is not validated and the workflow may fail or produce artifacts untested
on the supported versions.

Agent Prompt

### Issue description
The repo's CI workflow is pinned to a Node version that does not reflect the package's declared engine range after this PR.

### Issue Context
`package.json` now declares `engines.node: ">=18.0.0"`, but `.github/workflows/ci.yml` still runs CI on Node `22.22.0`.

### Fix Focus Areas
- package.json[142-144]
- .github/workflows/ci.yml[15-27]

### Suggested fix
- Update `.github/workflows/ci.yml` to test on supported versions (at minimum Node 18, and optionally also Node 20) via a matrix, or pin to an appropriate LTS version consistent with the engine policy.

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