Collector.js Breaks becuause ""stream" has been externalized"

[rtarling]

Describe the bug

I am calling AWS s3 Send command. This seems to call collector.js, which is used by smithy, which is used by AWS.

I get this error: TypeError: Class extends value undefined is not a constructor or null

I think it is caused by this:
browser-external:stream:9 Module "stream" has been externalized for browser compatibility. Cannot access "stream.Writable" in client code. See https://vite.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.

How can I get around this?

Reproduction

N/A

Steps to reproduce

As above.

System Info

System:
    OS: Windows 11 10.0.26200
    CPU: (24) x64 12th Gen Intel(R) Core(TM) i9-12900T
    Memory: 41.16 GB / 63.68 GB
  Binaries:
    Node: 22.14.0 - C:\Program Files\nodejs\node.EXE
    npm: 11.11.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 145.0.7632.117
    Edge: Chromium (143.0.3650.75)
    Internet Explorer: 11.0.26100.7309
  npmPackages:
    @vitejs/plugin-vue: latest => 6.0.4
    vite: latest => 7.3.1

Used Package Manager

npm

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[rtarling]

I have deleted package-lock.json and node_modues and done an npm install just to make sure there wasn't any mis-configuration. Didn't fix it,

[travisbreaks]

The AWS SDK v3 ships separate entry points for Node.js and the browser. Vite picks the right one through the browser field in each package's package.json. The problem is that some Smithy packages (the serialization layer under the SDK) still import Node.js stream on certain code paths, and Vite replaces Node built-ins with empty stubs for browser builds.

Two options depending on your setup:

Option A: Polyfill stream (quick fix)

npm install stream-browserify

// vite.config.js
import { defineConfig } from 'vite'

export default defineConfig({
  resolve: {
    alias: {
      stream: 'stream-browserify',
    },
  },
})

This gives Smithy a working stream.Writable in the browser.

Option B: Force the browser bundle resolution

If Option A pulls in more than you want, tell Vite to pre-bundle the SDK so it resolves browser entry points cleanly:

// vite.config.js
export default defineConfig({
  optimizeDeps: {
    include: ['@aws-sdk/client-s3'],
  },
})

This forces Vite's dependency optimizer to crawl the SDK upfront and resolve the browser field in every nested Smithy package, which should avoid the Node.js stream import entirely.

If you are running this in SSR mode, the fix is different: add the SDK to ssr.noExternal so Vite bundles it instead of treating it as an external Node module:

export default defineConfig({
  ssr: {
    noExternal: ['@aws-sdk/client-s3', '@smithy/*'],
  },
})

[rtarling]

Hi Many thanks for the quick turnaround on this. Option B makes no difference at all. Option A exposes this new error: “browser-external:node:process:9 Module "node:process" has been externalized for browser compatibility. Cannot access "node:process.versions" in client code. See https://vite.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.” I have also tried using the libraty “vite-plugin-node-polyfills” but this gives similar results to “stream-browserify”. As a fallback for now I am going to have to use pre-signed URLs which require more overhead/inefficiency/cost in calling and also in all the backend plumbing. Any other ideas, or do you know when this will be fixed in Smithy? The AWS SDK library is very important, and Vite is widely used now, so I am surprised this isn’t being fixed as a priority at the source. Thanks Roland From: travisBREAKS ***@***.***> Sent: Tuesday, 3 March 2026 06:12 To: vitejs/vite ***@***.***> Cc: Roland Tarling ***@***.***>; Author ***@***.***> Subject: Re: [vitejs/vite] Collector.js Breaks becuause ""stream" has been externalized" (Discussion #21728) The AWS SDK v3 ships separate entry points for Node.js and the browser. Vite picks the right one through the browser field in each package's package.json. The problem is that some Smithy packages (the serialization layer under the SDK) still import Node.js stream on certain code paths, and Vite replaces Node built-ins with empty stubs for browser builds. Two options depending on your setup: Option A: Polyfill stream (quick fix) npm install stream-browserify // vite.config.js import { defineConfig } from 'vite' export default defineConfig({ resolve: { alias: { stream: 'stream-browserify', }, }, }) This gives Smithy a working stream.Writable in the browser. Option B: Force the browser bundle resolution If Option A pulls in more than you want, tell Vite to pre-bundle the SDK so it resolves browser entry points cleanly: // vite.config.js export default defineConfig({ optimizeDeps: { include: ***@***.***/client-s3'], }, }) This forces Vite's dependency optimizer to crawl the SDK upfront and resolve the browser field in every nested Smithy package, which should avoid the Node.js stream import entirely. If you are running this in SSR mode, the fix is different: add the SDK to ssr.noExternal so Vite bundles it instead of treating it as an external Node module: export default defineConfig({ ssr: { noExternal: ***@***.***/client-s3', ***@***.***/*'], }, }) — Reply to this email directly, view it on GitHub<#21728 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AMF7KWTDR364MV7D4T7CIUD4OZSRZAVCNFSM6AAAAACWFABGHGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOJYGAZDIMY>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>