`@tanstack/ai-bedrock`: the AWS SDK cannot be bundled — variable-specifier dynamic imports defeat static bundlers (incl. esbuild)

[jsve]

TanStack AI version

0.40.0

Framework/Library version

esbuild

Describe the bug and the steps to reproduce it

Package: @tanstack/ai-bedrock@0.1.2

Summary

@tanstack/ai-bedrock loads its AWS SDK dependencies through dynamic imports whose specifier is a variable, not a string literal:

adapters/converse-text.js

importBedrockRuntime() {
  const mod = "@aws-sdk/client-bedrock-runtime";
  return import(/* @vite-ignore */ mod);
}

utils/auth.js

const mod = "@aws-sdk/credential-providers";
const { fromNodeProviderChain } = await import(/* @vite-ignore */ mod);

Static bundlers cannot resolve import() when the argument is a variable — they leave it as a runtime import and do not include the target in the output. This is not bun-specific; it is documented behaviour for esbuild too (esbuild only bundles import() with a string-literal specifier; a non-analyzable specifier is left external). As a result, @aws-sdk/client-bedrock-runtime, @aws-sdk/credential-providers, and their deep/subpath dependencies (@aws-sdk/token-providers, @smithy/core/schema, …) are excluded from the bundle. A build that uses this adapter therefore cannot be a self-contained bundle: the AWS SDK must still be resolved from node_modules at runtime.

Contradiction with the documented bundler support

The tree-shaking docs — https://tanstack.com/ai/latest/docs/advanced/tree-shaking#bundle-size-benefits — state:

Modern bundlers (Vite, Webpack, Rollup, esbuild) can easily eliminate unused code

and list, among the reasons this works:

No dynamic imports of unused code
Functions are statically analyzable
Clear dependency graphs

For the @tanstack/ai-bedrock adapter specifically, none of that holds for its AWS SDK edge: the imports are deliberately non-analyzable (the source comment says the variable specifier exists "so bundler dep scanners (e.g. Vite/esbuild optimizeDeps) cannot statically discover the AWS SDK"). So the very bundlers the docs advertise — esbuild included — cannot bundle the SDK that this adapter needs to run.

Reproduction

Bundle a server entry that uses the bedrock adapter with an esbuild-class bundler targeting a self-contained output, e.g.:

bun build src/server.ts --target bun --outdir dist

Observed:

• The output contains the verbatim const mod = "@aws-sdk/client-bedrock-runtime"; import(mod) — i.e. the SDK is left external, not bundled.
• Running the output in an environment with no node_modules fails at runtime, e.g. Cannot find module '@aws-sdk/token-providers' (Converse path) or Cannot find module '@smithy/core/schema' (auto-install path).

Making the specifiers string literals is the only way we found to get the bundler to include the SDK — confirming the variable specifier is precisely what blocks bundling.

Impact

Any consumer that ships @tanstack/ai-bedrock in a fully-bundled, node_modules-free artifact (single-file server bundle, some serverless/edge packaging, etc.) cannot do so: the AWS SDK silently drops out of the bundle and only fails at runtime. The adapter effectively requires node_modules to be present at runtime, which is at odds with the package's advertised bundler-friendliness.

Your Minimal, Reproducible Example - (Sandbox Highly Recommended)

see above

Screenshots or Videos (Optional)

NA

Do you intend to try to help solve this bug with your own PR?

None

Terms & Code of Conduct

• I agree to follow this project's Code of Conduct
• I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.