Skip to content

build: require Node >= 22 and build with Node 24 - #140

Open
antobinary wants to merge 1 commit into
v0.1.xfrom
node-24
Open

antobinary wants to merge 1 commit into
v0.1.xfrom
node-24

Conversation

@antobinary

Copy link
Copy Markdown
Member

What

Moves this plugin onto Node 24 and declares a supported-Node floor.

  • package.json gains an engines field: "node": ">=22", mirrored into
    package-lock.json so the two agree.
  • @types/node bumped to ^24.13.3 so the typings match the runtime the plugin
    is actually built with. It was declared twice, at ^20.3.1 and ^20.4.4;
    both are aligned here.
  • .nvmrc22 -> 24.
  • CI moved to Node 24:
    • release-publish-do-spaces.ymlnode-version: 20.x -> 24.x
    • release-upload-assets.ymlnode-version: 20.x -> 24.x
    • build-plugin-deb-package.yml — NodeSource setup_20.x -> setup_24.x
  • Debian packaging: debian/control Build-Depends raised from
    nodejs (>= 18) to nodejs (>= 22).

Why fewer workflow edits than the sibling repos

This repo is ahead of the others: ts-code-compilation.yml,
ts-code-validation.yml, unit-tests.yml and publish-tag.yml already read
their version from node-version-file: '.nvmrc' rather than hardcoding it. The
single .nvmrc bump moves all four at once.

Only the two release workflows still hardcode node-version, and they are
updated directly. Pointing them at .nvmrc too would be a sensible follow-up,
but is out of scope here.

Why >=22 in engines while .nvmrc says 24

They serve different purposes. engines is the compatibility contract for
anyone consuming or building the plugin, and 22 is still in maintenance so
there is no reason to lock it out. .nvmrc is the development and build
version — what CI and contributors actually run — and that is 24.

Same reasoning for Build-Depends: nodejs (>= 22): it is a minimum constraint,
not a pin, so the package stays buildable on a Node 22 builder while the version
used to build is pinned to 24 by the NodeSource line.

Testing

Against Node 24.20.0 / npm 11.19.0:

  • npm ci — PASS
  • npx tsc — PASS
  • npm run lint — PASS
  • npm run build-bundle — PASS
  • npm run test:unit:coverage — PASS

Notes for review

The package-lock.json diff is confined to the engines block and the
@types/node resolution. lockfileVersion is unchanged.

Add an `engines` floor of Node >= 22 to package.json and mirror it into
package-lock.json, and bump @types/node to ^24.13.3 so the typings match
the runtime the plugin is built with.

Move CI onto Node 24 (was Node 20). Raise the Debian Build-Depends floor
to nodejs (>= 22) and install Node 24 from NodeSource when building the
package.

Update .nvmrc to 24; CI reads the Node version from it.
@antobinary
antobinary requested a review from GuiLeme September 11, 2026 00:56

@imdt-claudiop imdt-claudiop left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved.

Same shape as bigbluebutton/bbb-plugin-picture-in-picture#43, which is already merged: Node 24 across the workflows, nodejs (>= 22) in debian/control, and engines.node >= 22 plus @types/node ^24.13.3 in package.json.

Checked out this branch and ran it on Node 24.9.0:

  • npm install clean, and package-lock.json shows no drift afterwards
  • npx tsc passes (same command as the ts-code-compilation check)
  • npm run lint passes (same command as the ts-code-validation check)
  • npm run build-bundle produces dist/BbbPluginPickRandomUser.js

I also scanned the rest of the tree for leftover references to the older Node line, and there are none.

This repo needed more than the reference PR did, and the extra pieces are all correct: .nvmrc moved 22 to 24, and the two release workflows (release-publish-do-spaces.yml, release-upload-assets.yml) were updated alongside the shared ones.

@github-actions

Copy link
Copy Markdown

This pull request has conflicts ☹
Please resolve those so we can review the pull request.
Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants