fix: backward-compat for ESM etherpad

[SamTV12345]

This PR makes the plugin backward-compatible with the upcoming ESM etherpad branch (ether/etherpad#7605).

Change: Migrate log4js from require("ep_etherpad-lite/node_modules/log4js") to ep_plugin_helpers/logger

This change is backward-compatible with the current CJS etherpad release.

[qodo-code-review]

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]

Review Summary by Qodo

Migrate to ep_plugin_helpers logger for ESM compatibility

✨ Enhancement 🐞 Bug fix

Walkthroughs

Description

• Migrate logging from direct log4js require to ep_plugin_helpers/logger
• Ensures ESM etherpad compatibility with stricter exports resolution
• Maintains backward compatibility with current CJS etherpad release
• Add ep_plugin_helpers dependency and bump version to 1.0.50

Diagram

flowchart LR
  A["Direct log4js require"] -->|"Replace with"| B["ep_plugin_helpers/logger"]
  B -->|"Supports"| C["ESM etherpad"]
  B -->|"Supports"| D["CJS etherpad"]

Loading

File Changes

1. index.js ✨ Enhancement +2/-2

Migrate logging to ep_plugin_helpers

• Replace require('ep_etherpad-lite/node_modules/log4js') with
 require('ep_plugin_helpers/logger')
• Update logger initialization from log4js.getLogger() to createLogger()
• Maintains same logger functionality with new import path

index.js

---

2. package.json Dependencies +4/-1

Add ep_plugin_helpers dependency and version bump

• Bump version from 1.0.49 to 1.0.50
• Add ep_plugin_helpers ^0.6.7 as a dependency
• Ensures required logger helper is available at runtime

package.json

---

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

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (1)

1. No regression test for logger 📘 Rule violation ☼ Reliability

Description

This PR changes the logging import to restore compatibility with upcoming ESM Etherpad, but it does
not add/update any regression test to verify the fix. Without a test, this compatibility behavior
can silently regress in future changes.

Code

index.js[R4-6]

Evidence

Compliance ID 1 requires a regression test alongside bug fixes. The PR changes core behavior in
index.js (logger creation) and package.json (adds the new dependency) but does not introduce any
test entry in scripts or related test code changes.

AGENTS.md: Every Bug Fix Must Include a Regression Test in the Same Commit
index.js[4-6]
package.json[6-9]
package.json[37-39]

Agent prompt

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

## Issue description
A bug-fix/compatibility change was made (switching from `log4js` to `ep_plugin_helpers/logger`) without adding a regression test in the same commit.

## Issue Context
The project currently has no test script, so the fix is not automatically verifiable and could regress undetected.

## Fix Focus Areas
- index.js[4-6]
- package.json[6-9]
- test/logger-compat.test.js[1-120]

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

---

2. Lockfile not updated 🐞 Bug ☼ Reliability

Description

package.json adds the ep_plugin_helpers runtime dependency but pnpm-lock.yaml still has no
corresponding dependency entry, so pnpm i --frozen-lockfile will fail. This can block the
automated release workflow (and any other frozen-lockfile installs).

Code

package.json[R36-39]

Evidence

The PR introduces a new dependency in package.json, but the lockfile’s root importer section still
lists only devDependencies, and the release workflow requires a frozen lockfile install—these
together imply the workflow will fail until the lockfile is updated.

package.json[33-39]
pnpm-lock.yaml[7-20]
.github/workflows/npmpublish.yml[54-73]

Agent prompt

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

## Issue description
`package.json` now declares a new runtime dependency (`ep_plugin_helpers`), but `pnpm-lock.yaml` was not regenerated. Any CI/release step that runs `pnpm i --frozen-lockfile` will error due to the lockfile being out of sync with `package.json`.

## Issue Context
The release workflow explicitly installs with a frozen lockfile, which requires the lockfile to exactly match `package.json`.

## Fix Focus Areas
- package.json[33-39]
- pnpm-lock.yaml[7-20]
- .github/workflows/npmpublish.yml[54-73]

## What to change
1. Run `pnpm install` in the repo root to regenerate `pnpm-lock.yaml`.
2. Commit the resulting `pnpm-lock.yaml` changes (it should include `ep_plugin_helpers@^0.6.7` under the root importer dependencies and in the `packages:` section).
3. Re-run CI/release checks to confirm `pnpm i --frozen-lockfile` succeeds.

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

---

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

1. No regression test for logger 📘 Rule violation ☼ Reliability

This PR changes the logging import to restore compatibility with upcoming ESM Etherpad, but it does
not add/update any regression test to verify the fix. Without a test, this compatibility behavior
can silently regress in future changes.

Agent Prompt

## Issue description
A bug-fix/compatibility change was made (switching from `log4js` to `ep_plugin_helpers/logger`) without adding a regression test in the same commit.

## Issue Context
The project currently has no test script, so the fix is not automatically verifiable and could regress undetected.

## Fix Focus Areas
- index.js[4-6]
- package.json[6-9]
- test/logger-compat.test.js[1-120]

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

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

2. Lockfile not updated 🐞 Bug ☼ Reliability

package.json adds the ep_plugin_helpers runtime dependency but pnpm-lock.yaml still has no
corresponding dependency entry, so pnpm i --frozen-lockfile will fail. This can block the
automated release workflow (and any other frozen-lockfile installs).

Agent Prompt

## Issue description
`package.json` now declares a new runtime dependency (`ep_plugin_helpers`), but `pnpm-lock.yaml` was not regenerated. Any CI/release step that runs `pnpm i --frozen-lockfile` will error due to the lockfile being out of sync with `package.json`.

## Issue Context
The release workflow explicitly installs with a frozen lockfile, which requires the lockfile to exactly match `package.json`.

## Fix Focus Areas
- package.json[33-39]
- pnpm-lock.yaml[7-20]
- .github/workflows/npmpublish.yml[54-73]

## What to change
1. Run `pnpm install` in the repo root to regenerate `pnpm-lock.yaml`.
2. Commit the resulting `pnpm-lock.yaml` changes (it should include `ep_plugin_helpers@^0.6.7` under the root importer dependencies and in the `packages:` section).
3. Re-run CI/release checks to confirm `pnpm i --frozen-lockfile` succeeds.

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