build: require Node >= 22 and build with Node 24 - #140
antobinary wants to merge 1 commit into
Conversation
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.
imdt-claudiop
left a comment
There was a problem hiding this comment.
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 installclean, and package-lock.json shows no drift afterwardsnpx tscpasses (same command as the ts-code-compilation check)npm run lintpasses (same command as the ts-code-validation check)npm run build-bundleproducesdist/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.
|
This pull request has conflicts ☹ |
What
Moves this plugin onto Node 24 and declares a supported-Node floor.
package.jsongains anenginesfield:"node": ">=22", mirrored intopackage-lock.jsonso the two agree.@types/nodebumped to^24.13.3so the typings match the runtime the pluginis actually built with. It was declared twice, at
^20.3.1and^20.4.4;both are aligned here.
.nvmrc—22->24.release-publish-do-spaces.yml—node-version: 20.x->24.xrelease-upload-assets.yml—node-version: 20.x->24.xbuild-plugin-deb-package.yml— NodeSourcesetup_20.x->setup_24.xdebian/controlBuild-Depends raised fromnodejs (>= 18)tonodejs (>= 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.ymlandpublish-tag.ymlalready readtheir version from
node-version-file: '.nvmrc'rather than hardcoding it. Thesingle
.nvmrcbump moves all four at once.Only the two release workflows still hardcode
node-version, and they areupdated directly. Pointing them at
.nvmrctoo would be a sensible follow-up,but is out of scope here.
Why
>=22in engines while.nvmrcsays 24They serve different purposes.
enginesis the compatibility contract foranyone consuming or building the plugin, and 22 is still in maintenance so
there is no reason to lock it out.
.nvmrcis the development and buildversion — 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— PASSnpx tsc— PASSnpm run lint— PASSnpm run build-bundle— PASSnpm run test:unit:coverage— PASSNotes for review
The
package-lock.jsondiff is confined to theenginesblock and the@types/noderesolution.lockfileVersionis unchanged.