chore: updated clients to esm

[SamTV12345]

No description provided.

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

Review Summary by Qodo

Update CLI client to v4.0.2 with ESM migration

✨ Enhancement

Walkthroughs

Description

• Updated etherpad-cli-client dependency from v3.0.5 to v4.0.2
• Migrated test client script to ESM module format
• Updated load test workflow to use simplified package name
• Added libc platform specifications to lock file

Diagram

flowchart LR
  A["etherpad-cli-client v3.0.5"] -->|upgrade| B["etherpad-cli-client v4.0.2"]
  C["send_changesets.js<br/>CommonJS"] -->|migrate| D["send_changesets.mjs<br/>ESM"]
  E["etherpad-load-test-socket-io"] -->|simplify| F["etherpad-load-test"]
  B -->|ESM support| D

Loading

File Changes

1. src/package.json Dependencies +1/-1

Bump etherpad-cli-client to v4.0.2

• Updated etherpad-cli-client dependency from ^3.0.5 to ^4.0.2

src/package.json

---

2. src/tests/ratelimit/send_changesets.mjs ✨ Enhancement +3/-5

Migrate send_changesets to ESM module

• Converted from CommonJS (require) to ESM (import) syntax
• Changed const etherpad = require('etherpad-cli-client') to `import {connect} from
 'etherpad-cli-client'`
• Updated etherpad.connect() to connect()
• Added Number() conversion for process.argv[3] parameter
• Removed 'use strict' directive (not needed in ESM)

src/tests/ratelimit/send_changesets.mjs

---

3. src/tests/ratelimit/testlimits.sh ✨ Enhancement +4/-4

Update script references to .mjs extension

• Updated all references from send_changesets.js to send_changesets.mjs
• Changed 4 occurrences across different test commands

src/tests/ratelimit/testlimits.sh

---

View more (3)

4. src/tests/ratelimit/Dockerfile.anotherip ⚙️ Configuration changes +2/-2

Update Docker image for ESM client

• Updated etherpad-cli-client installation to specific version ^4.0.2
• Changed file reference from send_changesets.js to send_changesets.mjs

src/tests/ratelimit/Dockerfile.anotherip

---

5. .github/workflows/load-test.yml ⚙️ Configuration changes +3/-3

Simplify load test package name

• Simplified package name from etherpad-load-test-socket-io to etherpad-load-test in 3 workflow
 jobs
• Updated in build steps for load test installation

.github/workflows/load-test.yml

---

6. pnpm-lock.yaml Dependencies +41/-14

Update lock file with v4.0.2 and platform specs

• Updated etherpad-cli-client from version 3.0.5 to 4.0.2 with new integrity hash
• Removed async dependency from etherpad-cli-client in snapshot
• Added libc platform specifications to multiple Linux binary packages for better platform
 detection
• Updated ESLint plugin dependency resolution to remove redundant peer dependency specifications

pnpm-lock.yaml

---

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

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0)

1. Unpinned CI load-test install 🐞 Bug ☼ Reliability

Description

The load-test workflow installs etherpad-load-test globally without a version pin, so the job can
start failing (or change behavior) when the upstream package publishes a breaking release. This also
bypasses the repo’s lockfile determinism even though the workflow otherwise uses `pnpm install
--frozen-lockfile`.

Code

.github/workflows/load-test.yml[45]

+        run: sudo npm install -g etherpad-load-test

Evidence

The workflow explicitly relies on a frozen lockfile for repo dependencies, but then installs the
load test tool from npm without any version constraint; this makes the CI environment
non-reproducible and susceptible to upstream changes.

.github/workflows/load-test.yml[40-48]
.github/workflows/load-test.yml[73-77]
.github/workflows/load-test.yml[134-141]

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 load-test GitHub Actions workflow installs `etherpad-load-test` from npm without a version pin. This can cause CI drift/flakiness when the upstream package updates.

### Issue Context
The workflow otherwise uses `pnpm install --frozen-lockfile`, so the unpinned global npm install is the remaining non-deterministic piece.

### Fix Focus Areas
- .github/workflows/load-test.yml[42-46]
- .github/workflows/load-test.yml[73-77]
- .github/workflows/load-test.yml[135-139]

### Suggested fix
- Change the install commands to a pinned version, e.g. `sudo npm install -g etherpad-load-test@<known-good-version>`.
- (Optional) Consider installing it as a dev dependency in the repo and invoking via `pnpm exec`/`npx` so it is governed by `pnpm-lock.yaml`.

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

---

2. Caret version in Dockerfile 🐞 Bug ☼ Reliability

Description

src/tests/ratelimit/Dockerfile.anotherip installs etherpad-cli-client@^4.0.2, allowing the
container’s dependency version to drift across CI runs and diverge from pnpm-lock.yaml. Because
the rate-limit workflow rebuilds this image each run, upstream minor/patch releases can cause flaky
tests unrelated to Etherpad changes.

Code

src/tests/ratelimit/Dockerfile.anotherip[3]

+RUN npm i etherpad-cli-client@^4.0.2

Evidence

The Dockerfile uses a semver range (^4.0.2) rather than an exact version, and the CI workflow
rebuilds the image. Meanwhile, the repo lockfile pins etherpad-cli-client to 4.0.2, showing an
intended stable version that the Docker image does not currently follow.

src/tests/ratelimit/Dockerfile.anotherip[1-4]
.github/workflows/rate-limit.yml[48-53]
pnpm-lock.yaml[3176-3180]

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 `anotherip` ratelimit test container installs `etherpad-cli-client` using a caret range (`^4.0.2`), which allows the installed version to change over time and can introduce CI flakiness.

### Issue Context
The GitHub Actions rate-limit workflow rebuilds this image each run. The repo’s `pnpm-lock.yaml` already pins `etherpad-cli-client` to `4.0.2`, but the Dockerfile does not follow that exact pin.

### Fix Focus Areas
- src/tests/ratelimit/Dockerfile.anotherip[1-4]

### Suggested fix
- Replace `npm i etherpad-cli-client@^4.0.2` with `npm i etherpad-cli-client@4.0.2`.
- (Optional) If you want full lockfile parity, consider copying in a minimal `package.json` + lockfile and using `npm ci` inside the image build.

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

---