build: require Node >= 22 and build with Node 24 - #30
Merged
Merged
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.
Run npm audit fix, then take the two major upgrades it could not apply on its own: copy-webpack-plugin 12 -> 14 and webpack-dev-server 4 -> 6. Between them these clear the shell-quote and websocket-driver criticals and the serialize-javascript, sockjs and uuid advisories. Everything changed here is build tooling; none of it ships in the bundle. webpack-dev-server 6 was verified beyond a successful build by starting the dev server and confirming the custom devServer.app route for /manifest.json still answers 200. Pin watch back to ^0.13.0, the version the other repos already use. Its 1.x line pulls exec-sh and a prototype-pollution advisory in merge, and npm's own resolution for those advisories is 0.13.0. It only backs the lint:watch helper script.
imdt-claudiop
approved these changes
Sep 14, 2026
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/<plugin-name>.js
I also scanned the rest of the tree for leftover references to the older Node line, and there are none.
build: resolve npm audit advisories
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Moves the template onto Node 24 and declares a supported-Node floor.
package.jsongains anenginesfield:"node": ">=22", mirrored intopackage-lock.jsonso the two agree.@types/nodebumped^20.4.4->^24.13.3so the typings match the runtimethe plugin is actually built with.
ts-code-compilation.yml—node-version: 20.x->24.xts-code-validation.yml—node-version: 20.x->24.xpublish-tag.yml—node-version: '20'->'24'build-plugin-deb-package.yml— NodeSourcesetup_20.x->setup_24.xdebian/controlBuild-Depends raised fromnodejs (>= 18)tonodejs (>= 22).Why this one matters more than its diff suggests
This is the template new plugins are generated from, and its CI workflows are
the ones copied into the sibling repos (several carry commits literally titled
"chore: update CI from bbb-plugin-template"). Landing it means new plugins start
on Node 24 rather than inheriting Node 20 and needing this same change later.
Worth merging ahead of the others for that reason.
Why
>=22and not>=24The floor is the compatibility contract for anyone consuming or building a
plugin; 22 is still in maintenance and there is no reason to lock it out. The
preferred version is expressed where it takes effect — CI and the Debian build
both pin 24.
Build-Dependsfollows the same logic: 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, running the same chain CI does:
npm ci— PASSnpx tsc— PASSnpm run lint— PASSnpm run build-bundle— PASSTypeScript resolves to 5.6.3, comfortably above the 5.2 that
@types/node24requires for
Symbol.dispose/Disposable.Notes for review
The
package-lock.jsondiff is confined to theenginesblock and the@types/noderesolution.lockfileVersionis unchanged.@types/nodeis already declared only indevDependencieshere, which is thecorrect shape — several plugins generated from older revisions of this template
carry it in both sections and need a separate cleanup. Nothing to fix in the
template itself.