feat(js-sdk): run the template test suite on Deno

[mishushakov]

What

Extends the Deno vitest run (#1585) with the template project and fixes the real runtime bug the suite surfaced. Split out of #1594 (Bun counterpart: #1596).

// packages/js-sdk/package.json
"test:deno": "deno run -A npm:vitest run --project unit --project connectionConfig --project template",

Bug — Deno: template uploads used chunked transfer encoding

Deno's native fetch ignores an explicit Content-Length header on stream bodies and falls back to Transfer-Encoding: chunked — exactly the failure #1243 fixed for Node, since S3-compatible presigned PUT URLs reject chunked uploads with 501.

uploadFile now streams the spooled archive through undici's fetch (via the existing loadUndici() helper — undici 8 where it imports, undici 7 on Bun, global fetch where undici isn't resolvable, e.g. bundled apps), which honors the Content-Length header on stream bodies on every runtime. One upload path, no runtime sniffing.

Approaches rejected along the way, all verified empirically with 1GB uploads + RSS sampling:

• File-backed Blob body (fs.openAsBlob) — lazy on Node/Bun, but Deno's shim reads the whole file into memory eagerly (node:fs openAsBlob should be streaming denoland/deno#32316), and Bun infers an unstrippable MIME type from the extension whose Content-Type breaks presigned signatures (403 against production storage).
• node:http(s) on Deno — works (and is memory-bounded), but can't be unified: Bun's node:http ignores abort signals, and it's a second code path.

Known caveat: Deno's Readable.toWeb shim has no backpressure, so the archive is buffered in memory during upload on Deno (Node and Bun stream in lockstep with the socket). Filed upstream as denoland/deno#36275 — accepted as Deno's to fix rather than worked around here.

As part of this, tarFileStream became spoolTarArchive, returning { path, size, cleanup } with caller-owned cleanup instead of a self-deleting read stream. tests/template/uploadFile.test.ts also asserts no Content-Type header is sent.

Python SDK parity

Intentionally none: upload_file already sends a sized file body via httpx.

Testing

• Real template builds (tests/template/build.test.ts, against prod S3 presigned URLs) green under Node, Deno, and Bun
• uploadFile + spoolTarArchive suites green under Node, Deno, and Bun
• tests/template/abortSignal.test.ts green under Deno
• pnpm build, lint, typecheck, prettier --check clean

🤖 Generated with Claude Code

[cursor]

PR Summary

Overview
Unable to generate summary.

^{Reviewed by Cursor Bugbot for commit 119bdd8. Bugbot is set up for automated code reviews on this repo. Configure here.}

[changeset-bot]

🦋 Changeset detected

Latest commit: 119bdd8

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
e2b	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

Package Artifacts

Built from 963ce58. Download artifacts from this workflow run.

JS SDK (e2b@2.35.4-deno-template-tests.0):

npm install ./e2b-2.35.4-deno-template-tests.0.tgz

CLI (@e2b/cli@2.15.1-deno-template-tests.0):

npm install ./e2b-cli-2.15.1-deno-template-tests.0.tgz

Python SDK (e2b==2.34.0+deno.template.tests):

pip install ./e2b-2.34.0+deno.template.tests-py3-none-any.whl

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 97fa550dc4

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[claude]

No bugs found by me or the bug-hunting system, but I'd like a human to weigh in given the change touches the presigned-upload networking path used by real template builds. Beyond the reported findings, I checked whether the new typed-blob fallback branch (blob.stream() + explicit Content-Length, added for Bun's MIME-type inference) is exercised by any test in this diff — it isn't; uploadFile.test.ts only covers the untyped-blob (blob.type === '') path that Node/Deno take, since fs.openAsBlob returns a typeless blob on Node. The Bun branch's correctness currently rests on the PR description's account of manual production testing rather than an automated check.

Extended reasoning...

Overview

This PR extends the Deno vitest run with the template project and changes uploadFile in buildApi.ts to send the spooled tar archive as a file-backed Blob (via fs.openAsBlob) instead of a Node Readable stream with an explicit Content-Length. The reason is that Deno's fetch ignores Content-Length on stream bodies and falls back to chunked transfer encoding, which S3-compatible presigned PUT URLs reject. tarFileStream was also renamed to spoolTarArchive, returning { path, size, cleanup } with caller-owned cleanup instead of a self-deleting stream — cleaner ownership semantics, and the tests were updated accordingly.

Security risks

Low. No new user input handling, auth, or crypto — this is an internal upload path to a presigned S3-style URL. The main risk category is functional correctness: sending the wrong headers (extra Content-Type, wrong Content-Length, or chunked encoding) breaks presigned-URL signature validation and causes uploads to fail with 403/501, not a security exposure.

Level of scrutiny

This warrants more than a rubber stamp: it changes a production-critical upload code path (every template build goes through uploadFile) and introduces runtime-dependent branching (feature-detected via blob.type) whose correctness depends on subtle, differing behavior across Node, Deno, and Bun's fetch/Blob implementations. The Node and Deno paths are exercised by the updated unit test and the real test:deno run (523 passed per the PR description). However, the typed-blob fallback branch — added specifically to fix Bun's inferred-MIME-type behavior — is not covered by any test in this diff; test:bun in package.json still only runs unit/connectionConfig, not template (that's deferred to the sibling PR #1594). The PR description states the Bun 403 was "observed... against production storage" but there's no automated regression test in this PR that would catch a regression in that branch.

Other factors

The rest of the diff is low-risk: a workflow comment reword, a package.json script addition (--project template for Deno), and mechanical test-file updates to match the new spoolTarArchive API (stream-based extraction replaced with file-path-based extraction, cleanup assertions added). These are straightforward and correctly mirror the implementation change. No CODEOWNERS-restricted files are touched, and the bug-hunting system found nothing. My deferral is specifically about the untested Bun-specific branch in critical upload code, not about any confirmed defect.