Update dependency @types/node to v24#600
Conversation
|
d529c85 to
44fd869
Compare
217c07a to
3ed082d
Compare
3ed082d to
b12c26d
Compare
8a2257b to
f579b22
Compare
f579b22 to
356e04e
Compare
336234a to
4f51e73
Compare
98822e3 to
fb3fd92
Compare
9839daa to
8a6032c
Compare
ff32a2b to
5cf646f
Compare
5cf646f to
4102a29
Compare
4102a29 to
2913e76
Compare
2913e76 to
6deda19
Compare
1800b24 to
eac684c
Compare
130a7c3 to
bf916c1
Compare
493ba0b to
9ab317f
Compare
9d34075 to
64a1d82
Compare
| "@edge-runtime/vm": "^5.0.0", | ||
| "@livekit/changesets-changelog-github": "^0.0.4", | ||
| "@types/node": "^20.10.1", | ||
| "@types/node": "^24.0.0", |
There was a problem hiding this comment.
🚩 Major version jump in @types/node may introduce breaking type changes
The livekit-server-sdk package jumps from @types/node@^20 to @types/node@^24, skipping two major versions (21, 22, 23). While this is only a devDependency and won't affect runtime behavior, @types/node major versions can introduce breaking changes to type definitions (e.g., removed or restructured types for Node.js APIs like Buffer, stream, crypto, etc.). The livekit-rtc package has a smaller jump from ^22 to ^24. Any type incompatibilities would surface during tsc compilation in CI, but it's worth confirming CI passes cleanly before merging.
Was this helpful? React with 👍 or 👎 to provide feedback.
| "devDependencies": { | ||
| "@bufbuild/protobuf": "^1.10.1", | ||
| "@types/node": "^22.13.10", | ||
| "@types/node": "^24.0.0", |
There was a problem hiding this comment.
🚩 @types/node v24 may expose APIs unavailable in supported Node versions
Both packages declare "node": ">= 18" in their engines field (packages/livekit-rtc/package.json:74, packages/livekit-server-sdk/package.json:65), meaning they claim to support Node 18, 20, 22, etc. However, @types/node@^24 provides type definitions for the Node.js 24 API surface. This means TypeScript will happily allow usage of APIs introduced in Node 20, 22, or 24 (e.g., changes to fs, crypto, stream, or global type changes) without any compiler error — even though those APIs would fail at runtime on Node 18.
This isn't a bug in itself (it's a dev dependency, so it doesn't affect consumers' type resolution), but it does reduce the safety net for contributors: new code could accidentally rely on newer Node APIs that don't exist in Node 18, and TypeScript won't catch it. Typically, @types/node major version should align with the minimum supported Node version to prevent this class of issue.
Was this helpful? React with 👍 or 👎 to provide feedback.
64a1d82 to
6cdd179
Compare
This PR contains the following updates:
^20.10.1→^24.0.0^22.13.10→^24.0.0Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR was generated by Mend Renovate. View the repository job log.