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.17.0: 24.17.0

Compare Source

Node.js 24.17.0

v24.16.0: 24.16.0

Compare Source

Node.js 24.16.0

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.

[doubleword-code]

Summary

This PR updates the TypeScript SDK's Node.js version from 22 to 24 across CI workflows, publish workflows, and dev dependencies. The change is straightforward and aligns with Node.js 24's current status (released May 2025, transitioning to LTS in October 2026).

Verdict: Ready to approve — no blocking issues identified.

Research notes

1. Node.js 24 Release Info (source):

   • Released May 6, 2025 as "Current" release
   • V8 13.6 engine update with new JS features (Float16Array, explicit resource management, RegExp.escape)
   • npm 11 upgrade
   • AsyncLocalStorage now defaults to AsyncContextFrame
   • URLPattern exposed globally
   • Undici 7 for HTTP client capabilities
   • Several deprecations: url.parse(), SlowBuffer, tls.createSecurePair, Zlib classes without new

2. Node.js Support Schedule (source):

   • Node 24 becomes LTS in October 2026 (4 months from now)
   • Active support until October 2026, security support until April 2028
   • Production applications should use Active LTS or Maintenance LTS releases

3. Code Compatibility Check:

   • The TypeScript SDK (client.ts) uses globalThis.crypto.randomUUID() — compatible with Node 24
   • Uses native fetch() — powered by Undici 7 in Node 24, no breaking changes for this usage pattern
   • No usage of deprecated APIs (url.parse(), SlowBuffer, tls.createSecurePair)
   • No direct AsyncLocalStorage usage that could be affected by the AsyncContextFrame default change
   • The openai SDK (v6.41.0) supports Node.js 20+ per their README, and ecosystem testing includes Node 24

4. Dependency Changes:

   • @types/node: ^22.0.0 → ^24.0.0 (resolved to 24.12.4)
   • undici-types: 6.21.0 → 7.16.0 (aligns with Undici 7 in Node 24)
   • Removed peer: true flags from esbuild, fsevents, typescript — these are now optional peer dependencies in newer versions, not a concern for this project

Suggested next steps

1. Merge as-is — the change is safe and follows Renovate's automated dependency management best practices.

2. Optional follow-up: Consider updating the README or documentation to explicitly state Node.js 24 support alongside the existing ">=18" engine requirement in package.json. This is not required since Node 24 is backward-compatible, but may help users understand tested versions.

3. Monitor after merge: Once merged, verify that CI passes on Node 24 and that the build artifact works correctly in the intended runtime environments (Node, Bun, Deno, Cloudflare Workers).

General findings

No correctness, security, or compatibility issues were identified. The code does not use any Node 24 deprecated or removed APIs. The openai package dependency constraint (">=4.0.0 <7") is compatible with the current v6.x release, which has been tested with Node 24 per their ecosystem tests.

One minor observation: Node 24 is still in "Current" status (not yet LTS as of June 2026). For production deployments, teams may prefer to wait until October 2026 when Node 24 transitions to Active LTS. However, using "Current" releases in CI/testing is appropriate to ensure forward compatibility.

[doubleword-code]

Summary

This PR updates the TypeScript SDK's Node.js dependency from version 22 to version 24 across CI workflows, publish workflows, and dev dependencies (@types/node). This is a routine dependency upgrade that brings the project to the latest Current release of Node.js.

Verdict: Approved with minor considerations — the change is straightforward and low-risk, but there are a few items worth noting before merging.

---

Research notes

I reviewed the Node.js 24.0.0 release notes and identified the following relevant changes:

Key changes in Node.js 24

• V8 13.6 — New JavaScript features (Float16Array, explicit resource management, RegExp.escape)
• npm 11 — Performance and security improvements
• Undici 7 — HTTP client used by fetch API; breaking changes include removed interceptors and stricter brand checks
• URLPattern as global — Now available without imports
• Deprecations — url.parse(), SlowBuffer, tls.createSecurePair, and others marked for removal

@types/node v24

The DefinitelyTyped package @types/node@24 includes updated type definitions matching Node.js 24 APIs, including the new globals and updated Undici types.

Compatibility assessment for autobatcher

The TypeScript SDK uses:

• Standard fetch() API (via Undici, now v7 in Node 24)
• node:http for the serve mode proxy
• No deprecated APIs identified in the codebase

The _fetchResults() method in client.ts (line 378–401) makes raw fetch() calls and reads response headers/body. Undici 7 changed some internals but maintains backward-compatible Response API behavior.

---

Suggested next steps

1. Verify CI passes — Ensure the GitHub Actions workflow completes successfully with Node 24, particularly the npm run build step.
2. Test serve mode locally — The serve.ts file uses node:http and raw fetch() calls; confirm it works end-to-end with Node 24.
3. Consider pinning @types/node more precisely — The current ^24.0.0 allows minor/patch updates. Consider whether stricter pinning is desired for reproducible builds.

---

General findings

✅ Positive observations

• Minimal surface area — Only 4 files changed; no core logic modifications.
• No deprecated API usage — The codebase doesn't use url.parse(), SlowBuffer, or other deprecated features flagged in Node 24.
• Runtime-agnostic design — The client.ts avoids node: imports (except in serve.ts/cli.ts), aligning with the repo's goal of supporting Cloudflare Workers, Deno, and Bun.

⚠️ Potential considerations (non-blocking)

1. Undici 7 breaking changes — While the fetch() API remains stable, Undici 7 removed some internal features (e.g., interceptors). The autobatcher doesn't use these, but if future enhancements plan to customize fetch behavior, the new DNS interceptor API (undici#3490) may be relevant.

2. Node 24 is "Current", not LTS — Node 24 will become LTS in October 2025. If production stability is a priority, consider whether targeting an LTS version (Node 22) is preferable until Node 24 enters LTS. That said, testing on Current is reasonable for early compatibility validation.

3. Peer dependency considerations — The package.json specifies "engines": { "node": ">=18" }. This is still accurate, but you may want to explicitly test against Node 24 in your matrix to ensure broad compatibility.

---

Conclusion

This is a well-scoped dependency update with minimal risk. The changes are confined to configuration files and lockfile updates. No code modifications are required, and the autobatcher codebase does not rely on any deprecated or removed Node.js APIs.

Recommendation: Approve and merge, pending successful CI run.