build: require Node >= 22 and build with Node 24 - #140
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 ☹ |
v0.1.x moved on: #134 adopted @bigbluebutton/bbb-ui-components-react and 8c6e080 pinned every dependency to an exact version. Both touched package.json and package-lock.json, which conflicted with this branch. Resolved in favour of v0.1.x, then re-applied this branch's two intents: * engines.node >= 22 * @types/node 24.13.3 in dependencies and devDependencies, written without a caret so v0.1.x's new exact-pin convention holds package-lock.json was regenerated from the resolved package.json rather than hand-merged, using npm 11 (the npm Node 24 ships) so the lockfile keeps the libc metadata v0.1.x's generator wrote. The resulting lockfile delta is only @types/node, its undici-types bump, and engines. The workflow, .nvmrc and debian/control changes merged without conflict. Verified on the merge result: tsc --noEmit clean, eslint clean, 69/69 unit tests across 13 files, production bundle builds. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
#140 landed on v0.1.x, which also brought in #134 (@bigbluebutton/bbb-ui-components-react) and 8c6e080, pinning every dependency to an exact version. That conflicted with this branch, whose only change is a one-line removal that no longer matched its context: the entry is now "@types/node": "24.13.3" rather than "^24.13.3". Resolved in favour of v0.1.x, then re-applied this branch's single intent: drop @types/node from dependencies, keep it in devDependencies. devDependencies auto-merged to v0.1.x's exact 24.13.3, so the exact-pin convention holds. package-lock.json was regenerated from the resolved package.json with npm 11 (the npm Node 24 ships), matching the generator v0.1.x used. The diff against the base is again exactly two deletions. Verified: npm ci, tsc --noEmit clean, eslint clean, 69/69 unit tests across 13 files with coverage, production bundle builds. Type resolution is unaffected -- devDependencies still supplies @types/node 24.13.3. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.