mirror of
https://github.com/ether/etherpad-lite.git
synced 2026-07-17 16:47:05 +00:00
* docs: bump documented Node.js minimum to 25 Etherpad is moving its supported Node.js floor to >= 25 (CI matrix is already pinned to 25 across all workflows on the node25-corepack-pnpm11 work). Sync the user-facing documentation so the install instructions, requirements section, and plugin metadata example all reflect the new minimum instead of Node 22 / 12.17. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore: require Node.js >= 25 (engines, installers, Dockerfile, snap, CI) #7747 added Node 25 *support* but left the floor at Node 22. This commit completes the cutover so the runtime requirement matches the documentation bumped in the previous commit. - package.json: engines.node ">=22.13.0" → ">=25.0.0" - bin/functions.sh, bin/installer.sh, bin/installer.ps1: REQUIRED_NODE bumped to 25 (controls the error message users see when they invoke the installer or pnpm scripts on an older Node) - Dockerfile: base image node:22-alpine → node:25-alpine (×2). Corepack comment updated: Node 25 no longer ships corepack at all, so we install it from npm rather than refreshing a stale signing-key list - snap/snapcraft.yaml: pinned NODE_VERSION 22.22.2 → 25.9.0 and the surrounding design notes rewritten to reflect Node 25 instead of 22 - .github/workflows/*.yml: matrix dropped from [22, 24, 25] to just [25] (anything older now fails engines anyway). Stale comments in build-and-deploy-docs.yml referencing vite 8's 22.12 floor cleaned up - bin/plugins/lib/npmpublish.yml: setup-node 22 → 25 so the plugin template propagated to every ether/* plugin matches the new minimum Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(docker): install pnpm directly on Node 25 (no corepack) node:25-alpine doesn't ship corepack but does pre-install yarn at /usr/local/bin/yarn, so `npm install -g corepack@latest` fails with EEXIST trying to register its yarn shim. Per #7747, end-users install pnpm via plain `npm install -g pnpm` on Node 25 — use the same flow in the Dockerfile (and remove the unused yarn binary so it doesn't sit on PATH inside the image). Drops COREPACK_HOME and the related issue-7687 cache-sharing tweak since there's no corepack shim to share. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
99 lines
4.6 KiB
YAML
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 25 to match the rest of CI and the
|
|
# Etherpad core minimum.
|
|
node-version: 25
|
|
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
|