etherpad-lite/bin/plugins/lib/npmpublish.yml
John McLear 04045fe532
Roll Node.js floor back to >= 24 (Active LTS) — closes #7779 (#7781)
* Roll Node.js floor back to >= 24 (Active LTS)

Closes #7779.

#7779 originally proposed bumping past the Node 25 stop-gap to Node 26.
After re-checking the release schedule, the cleaner LTS target is
actually Node 24:

- Node 24 (Krypton) is currently in Active LTS, supported until ~May 2028.
- Node 25 hit end-of-life on April 10 2026 — the floor merged in
  #7752 / #7749 / #7754 a day ago ships an already-EOL major.
- Node 26 was released May 5 2026 and does not enter Active LTS until
  October 2026.

So this PR reverts the Node 25 ratchet from those three PRs and lands
on Node 24 — Etherpad's runtime floor stays on a supported LTS for the
next ~2 years.

Runtime / infra
- `package.json` + `src/package.json`: `engines.node` `>=25.0.0` -> `>=24.0.0`
- `bin/functions.sh`, `bin/installer.sh`, `bin/installer.ps1`:
  `REQUIRED_NODE_MAJOR` 25 -> 24
- `Dockerfile`: `node:25-alpine` -> `node:24-alpine` (both stages).
  Corepack-via-npm workaround is intentionally kept: it works on
  Node 24 (which still ships corepack) and on Node 25+ (which doesn't),
  so the same recipe survives the next LTS bump without churn. Comments
  reworded accordingly.
- `snap/snapcraft.yaml`: pinned `NODE_VERSION` 25.9.0 -> 24.15.0; design
  notes + corepack comment adjusted
- `packaging/nfpm.yaml`: `nodejs (>= 25)` -> `nodejs (>= 24)` in
  top-level depends + deb/rpm overrides
- `packaging/bin/etherpad`: comment matches the new pin
- `packaging/README.md`: build prereqs + apt install snippet point at
  `node_24.x`; the long-stale "engines.node floor is 20" line is fixed
  while we're here
- `.github/workflows/*.yml`: setup-node `node-version` 25 -> 24 across
  every workflow; backend / frontend-admin / upgrade matrices
  `[25]` -> `[24]`
- `.github/workflows/deb-package.yml`: `NODE_MAJOR=25` + `node_25.x`
  smoke-test installer -> 24
- `bin/plugins/lib/npmpublish.yml`: 25 -> 24 (template propagates to
  the ~80 ether/* plugins via update-plugins workflow)

Docs
- `README.md`: install one-liner + Requirements -> Node.js >= 24
- `doc/npm-trusted-publishing.md`: runner requirement -> Node 24
- `doc/plugins.md` / `doc/plugins.adoc`: plugin metadata example
  `engines.node` -> `">=24.0.0"`

@types/node is left at ^25.8.0 — newer type definitions cover Node 24
runtime fine and avoid an unnecessary lockfile churn.

Companion homepage one-liner change to follow on ether/ether.github.com.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs(plugins): example engines.node = ">=22.0.0", not core's floor

Plugin code is overwhelmingly ace-hook glue and rarely uses Node-version-
specific APIs, so plugin engines.node should reflect the plugin's own
requirements, not track core. Showing core's 24-floor in the example
encouraged plugin authors to blindly copy a tighter pin than necessary
and locked plugins out of being installable on older Etherpad/Node
deployments. Use the most-recent Node LTS that has actually reached EOL
(20 -> EOL April 2026) as the example floor, i.e. >=22.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-16 13:07:59 +01:00

99 lines
4.6 KiB
YAML

# This workflow will run tests using node and then publish a package to the npm registry when a release is created
# For more information see: https://help.github.com/actions/language-and-framework-guides/publishing-nodejs-packages
#
# Publishing uses npm Trusted Publishing (OIDC) — no NPM_TOKEN secret is
# required. Each package must have a trusted publisher configured on npmjs.com
# pointing at this workflow file. See:
# https://docs.npmjs.com/trusted-publishers
name: Node.js Package
on:
workflow_call:
jobs:
publish-npm:
runs-on: ubuntu-latest
permissions:
contents: write # for the atomic version-bump push (branch + tag)
id-token: write # for npm OIDC trusted publishing
steps:
- uses: actions/setup-node@v6
with:
# OIDC trusted publishing needs npm >= 11.5.1, which requires
# Node >= 22.9.0. Use Node 24 to match the rest of CI and the
# Etherpad core minimum.
node-version: 24
registry-url: https://registry.npmjs.org/
- name: Upgrade npm to >=11.5.1 (required for trusted publishing)
run: npm install -g npm@latest
- name: Check out Etherpad core
uses: actions/checkout@v6
with:
repository: ether/etherpad-lite
- uses: pnpm/action-setup@v5
name: Install pnpm
with:
version: 10
run_install: false
- name: Get pnpm store directory
shell: bash
run: |
echo "STORE_PATH=$(pnpm store path --silent)" >> $GITHUB_ENV
- uses: actions/cache@v5
name: Setup pnpm cache
with:
path: ${{ env.STORE_PATH }}
key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
restore-keys: |
${{ runner.os }}-pnpm-store-
-
uses: actions/checkout@v6
with:
fetch-depth: 0
-
name: Bump version (patch)
run: |
LATEST_TAG=$(git describe --tags --abbrev=0) || exit 1
NEW_COMMITS=$(git rev-list --count "${LATEST_TAG}"..) || exit 1
[ "${NEW_COMMITS}" -gt 0 ] || exit 0
git config user.name 'github-actions[bot]'
git config user.email '41898282+github-actions[bot]@users.noreply.github.com'
pnpm i
# `pnpm version patch` bumps package.json, makes a commit, and creates
# a `v<new-version>` tag. Capture the new tag name from package.json
# rather than parsing pnpm's output, which has historically varied.
pnpm version patch
NEW_TAG="v$(node -p "require('./package.json').version")"
# CRITICAL: use --atomic so the branch update and the tag update
# succeed (or fail) as a single transaction on the server. The old
# `git push --follow-tags` was non-atomic per ref: if a concurrent
# publish run won the race, the branch fast-forward would be rejected
# but the tag push would still land — leaving a dangling tag with no
# matching commit on the branch. Subsequent runs would then forever
# try to bump to the same already-existing tag and fail with
# `tag 'vN+1' already exists`. With --atomic, a rejected branch push
# rejects the tag push too, and the next workflow tick can retry
# cleanly against the up-to-date refs.
git push --atomic origin "${GITHUB_REF_NAME}" "${NEW_TAG}"
# This is required if the package has a prepare script that uses something
# in dependencies or devDependencies.
-
run: pnpm i
# `npm publish` must come after `git push` otherwise there is a race
# condition: If two PRs are merged back-to-back then master/main will be
# updated with the commits from the second PR before the first PR's
# workflow has a chance to push the commit generated by `npm version
# patch`. This causes the first PR's `git push` step to fail after the
# package has already been published, which in turn will cause all future
# workflow runs to fail because they will all attempt to use the same
# already-used version number. By running `npm publish` after `git push`,
# back-to-back merges will cause the first merge's workflow to fail but
# the second's will succeed.
#
# Use `npm publish` directly (not `pnpm publish`) because OIDC trusted
# publishing requires npm CLI >= 11.5.1 and `pnpm publish` shells out to
# whichever `npm` is on PATH; calling `npm` directly avoids any shim
# ambiguity.
- name: Publish to npm via OIDC
run: npm publish --provenance --access public