chore(deps): update dependency node to v24

[renovate]

This PR contains the following updates:

Package	Type	Update	Change	Age	Confidence
node	uses-with	major	22 → 24
@types/node (source)	devDependencies	major	^22.0.0 → ^24.0.0

---

Release Notes

actions/node-versions (node)

v24.15.0: 24.15.0

Compare Source

Node.js 24.15.0

v24.14.1: 24.14.1

Compare Source

Node.js 24.14.1

v24.14.0: 24.14.0

Compare Source

Node.js 24.14.0

v24.13.1: 24.13.1

Compare Source

Node.js 24.13.1

v24.13.0: 24.13.0

Compare Source

Node.js 24.13.0

v24.12.0: 24.12.0

Compare Source

Node.js 24.12.0

v24.11.1: 24.11.1

Compare Source

Node.js 24.11.1

v24.11.0: 24.11.0

Compare Source

Node.js 24.11.0

v24.10.0: 24.10.0

Compare Source

Node.js 24.10.0

v24.9.0: 24.9.0

Compare Source

Node.js 24.9.0

v24.8.0: 24.8.0

Compare Source

Node.js 24.8.0

v24.7.0: 24.7.0

Compare Source

Node.js 24.7.0

v24.6.0: 24.6.0

Compare Source

Node.js 24.6.0

v24.5.0: 24.5.0

Compare Source

Node.js 24.5.0

v24.4.1: 24.4.1

Compare Source

Node.js 24.4.1

v24.4.0: 24.4.0

Compare Source

Node.js 24.4.0

v24.3.0: 24.3.0

Compare Source

Node.js 24.3.0

v24.2.0: 24.2.0

Compare Source

Node.js 24.2.0

v24.1.0: 24.1.0

Compare Source

Node.js 24.1.0

v24.0.2: 24.0.2

Compare Source

Node.js 24.0.2

v24.0.1: 24.0.1

Compare Source

Node.js 24.0.1

v24.0.0: 24.0.0

Compare Source

Node.js 24.0.0

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 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.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[doubleword-code]

Summary

This PR updates the TypeScript SDK's CI/CD pipelines and dev dependencies from Node.js 22 to Node.js 24. The changes touch workflow files (.github/workflows/ci.yml, .github/workflows/publish.yml), typescript/package.json, and typescript/package-lock.json.

Verdict: Needs Changes — While updating to the latest Node.js version is reasonable, there are several concerns that should be addressed before merging:

1. Node.js 24 is currently "Current" (not LTS) and won't become LTS until October 2025. Production build pipelines should use LTS versions.
2. No compatibility testing matrix — the package claims Node >=18 support but only tests on Node 24.
3. Undici 7 (included in Node 24) has breaking changes that could affect the fetch() usage in client.ts.

Research Notes

• Node.js 24 Release Notes: Released May 6, 2025. Key changes include V8 13.6, npm 11, Undici 7, URLPattern as global, AsyncLocalStorage defaulting to AsyncContextFrame.
• Node.js Release Schedule: Node 24 enters LTS in October 2025. Node 22 is currently Active LTS (until March 2026).
• Undici 7 Breaking Changes: Major version bump with potential HTTP client behavior changes.

Suggested Next Steps

1. Blocking: Change workflows to use Node 22 (LTS) instead of Node 24 (Current) for production builds.
2. Non-blocking: Add a test matrix to verify compatibility across Node 18, 20, 22, and 24.
3. Non-blocking: Document any known Undici 7 compatibility considerations or pin undici version if needed.

General Findings

1. Using Non-LTS Node.js Version for Production Builds

Node.js 24 is in "Current" status, meaning it's intended for library authors to add support but is not recommended for production use. The publish workflow (publish.yml) uses Node 24 to build and publish the npm package, which means the distributed artifacts are built with a non-LTS runtime.

Recommendation: Use Node 22 (Active LTS) for CI and publishing until Node 24 reaches LTS status in October 2025.

2. Missing Compatibility Testing Matrix

The package.json specifies "engines": { "node": ">=18" }, indicating support for Node 18, 20, 22, and 24. However, the CI only tests on Node 24. This creates a gap where compatibility with older supported versions is unverified.

Recommendation: Add a test matrix covering Node 18, 20, 22, and optionally 24.

3. Undici 7 Breaking Changes

Node 24 ships with Undici 7, which has breaking changes from Undici 6.x. The client.ts file uses fetch() directly at line 375 for fetching batch results. While the core functionality may work, subtle behavioral differences could exist.

Recommendation: Verify fetch() behavior with Undici 7, particularly around headers, streaming, and error handling.

4. AsyncLocalStorage Behavior Change

Node 24 changes AsyncLocalStorage to default to AsyncContextFrame. While this SDK doesn't directly use AsyncLocalStorage, the underlying OpenAI SDK might, and this could affect async context propagation in edge cases.

5. Test Runner API Changes

Node 24's test runner no longer returns promises from test() and t.test(). If tests are added in the future using Node's native test runner, they would need to be updated.

---

Overall Assessment: This is a routine dependency update, but the choice to use a non-LTS Node.js version for production builds is concerning. The PR should either target Node 22 (LTS) or explicitly document that Node 24 is intentional despite its "Current" status.

General findings (auto-demoted from inline due to pre-validation)

• Non-blocking typescript/src/client.ts:375 — This fetch() call uses Undici, which was upgraded from v6.x to v7.x in Node 24.
  • (demoted: path "typescript/src/client.ts" is not in the PR diff)

[doubleword-code]

Non-blocking: Consider adding a test matrix instead of only testing on Node 24.

Why it matters: The package.json declares support for node >= 18, but CI only validates against Node 24. This means compatibility with Node 18, 20, and 22 is unverified, which could lead to issues for users on LTS versions.

Suggested fix: Add a strategy matrix:

strategy:
  matrix:
    node-version: ["18", "20", "22", "24"]

Or at minimum test on both the oldest supported (18) and latest LTS (22).

[doubleword-code]

Blocking: Using Node.js 24 (Current, not LTS) for production builds is risky.

Why it matters: According to the Node.js release schedule, Node 24 won't enter LTS until October 2025. Production applications should use LTS releases for stability. The published npm package will be built with a non-LTS runtime, which could introduce unexpected behavior or incompatibilities.

Node 22 is currently Active LTS and more appropriate for production builds.

Suggested fix: Change to Node 22 (LTS):

node-version: "22"

Alternatively, if Node 24 is intentional, add a comment explaining the rationale.

[doubleword-code]

Non-blocking: Updating to @types/node@^24.0.0 aligns with the Node 24 target, but consider whether this is necessary.

Why it matters: The type definitions for Node 24 include APIs and types specific to Node 24. If the SDK should remain compatible with Node 18-22, using Node 24 types could inadvertently introduce incompatible type usage. The types should match the minimum supported version (Node 18), not the target version.

Suggested fix: Either:

1. Keep @types/node at ^22.0.0 (LTS) to ensure compatibility with Node 18-22, or
2. If Node 24-specific features are needed, update the engines field to require Node 24+.

[doubleword-code]

Summary

This PR updates the Node.js runtime from version 22 to version 24 across CI/CD workflows and updates the corresponding @types/node devDependency. The change is straightforward and follows Renovate's automated dependency management.

Verdict: Ready to approve — no blocking issues identified.

Research notes

I reviewed the Node.js 24 release notes to assess potential breaking changes:

• V8 13.6 — introduces new JS features (Float16Array, explicit resource management, RegExp.escape) but no breaking changes affecting this codebase
• Undici 7 — shipped with Node 24; the undici-types update from 6.21.0 to 7.16.0 in the lockfile reflects this
• Deprecations — url.parse(), SlowBuffer, tls.createSecurePair are deprecated/removed, but none are used in this codebase
• Globals — URLPattern now globally available; AsyncLocalStorage defaults to AsyncContextFrame

The TypeScript SDK code in client.ts, serve.ts, and cli.ts uses:

• globalThis.crypto.randomUUID() — ✅ compatible
• Native fetch() for batch result retrieval — ✅ compatible (standard API surface unchanged)
• node:http and node:util — ✅ stable APIs
• No deprecated APIs detected

Suggested next steps

1. Merge this PR — the update is safe and keeps the project current with the latest Node.js LTS track
2. Monitor CI — verify that type checking (npm run typecheck) and build (npm run build) pass on Node 24
3. Consider updating engines field (optional) — the current "node": ">=18" is still valid, but you could document tested versions like "node": ">=18.0.0" if desired

General findings

Lockfile peer dependency changes: The diff shows peer: true flags removed from esbuild and typescript entries in package-lock.json. This is a lockfile format normalization from npm 11 (shipped with Node 24) and does not affect functionality or installation behavior.

No code changes required: The autobatcher TypeScript SDK does not use any APIs that were broken or removed in Node 24. The update is purely infrastructural.