Introduction

This TypeScript error usually means the SDK types refer to the Web Streams API, but your TypeScript configuration does not include a declaration for ReadableStream. With AWS SDK v3, that often happens in projects that target Node.js, use an older TypeScript configuration, or have mismatched environment typings. The fix is usually not in the SDK call itself. It is in the project's type environment.

Why ReadableStream Appears at All

AWS SDK v3 is modular and shared across browser and server environments. Some response-body types and transport abstractions refer to stream types that TypeScript expects to find globally.

If the compiler knows about browser or Web Streams types, ReadableStream resolves cleanly. If it does not, you get TS2304.

Check tsconfig.json First

A common fix is to include the appropriate libraries in tsconfig.json.

1{
2  "compilerOptions": {
3    "target": "ES2021",
4    "module": "commonjs",
5    "lib": ["ES2021", "DOM"],
6    "strict": true
7  }
8}

Adding DOM makes the standard ReadableStream type available in many TypeScript setups. Even in a Node.js project, this can be the simplest fix when the code depends on Web-compatible stream typings.

Node Projects Also Need Current Environment Types

If the project targets Node.js, make sure the Node types and TypeScript version are recent enough for the runtime assumptions your stack is making.

npm install --save-dev typescript @types/node

Then confirm the compiler is actually using the intended version and configuration. Many stream-related type errors come from stale toolchain versions rather than from AWS SDK code.

Do Not Confuse Runtime Support with Type Support

A runtime may support streams while TypeScript still complains because the declaration environment is incomplete. Conversely, adding typings does not magically polyfill a missing runtime feature.

That is why you should treat compilation and execution as separate questions. First make the compiler understand the types. Then verify that the actual runtime environment supports the APIs the application uses.

Keep the Environment Model Consistent

Problems often come from mixing browser assumptions, Node assumptions, and library assumptions in one project. If the code is server-only, be intentional about which global types you include. If the code is shared between environments, be even more explicit.

This is one reason AWS SDK v3 errors can look surprising. The packages are modular, but the project's ambient type environment still needs to be coherent.

Once the environment model is consistent, the SDK types usually stop being the surprising part of the build.

A Minimal Example of the Kind of Code Involved

The error often shows up before your own code even does much with the stream.

1import { S3Client, GetObjectCommand } from "@aws-sdk/client-s3";
2
3const client = new S3Client({ region: "us-east-1" });
4
5async function main() {
6  const result = await client.send(new GetObjectCommand({
7    Bucket: "example-bucket",
8    Key: "file.txt"
9  }));
10
11  console.log(result.Body);
12}
13
14main();

If the project does not know what ReadableStream is, the error can surface from SDK type declarations before you even process result.Body.

Common Pitfalls

• Blaming the AWS SDK call when the real issue is the TypeScript environment configuration.
• Assuming Node runtime support and TypeScript type support are the same thing.
• Leaving tsconfig.json vague about the libraries the project expects.
• Using outdated TypeScript or @types/node versions with newer SDK packages.
• Adding random type packages without first checking which ambient type is actually missing.

Summary

• 'TS2304 Cannot find name 'ReadableStream' usually means your TypeScript libs do not declare that global type.'
• Start by checking tsconfig.json, especially the lib setting.
• Keep TypeScript and Node typings current when targeting Node.js.
• Separate compiler typing issues from runtime support issues.
• Treat AWS SDK v3 type errors as environment-configuration problems first, not API-usage problems first.