Fix: Amazon Bedrock provider still ships broken in the release bundle — missing dist/bundle/amazon-bedrock.js chunk (#751)

[kaluli123123]

Summary

The Amazon Bedrock provider has been broken in every release built from the Node bundle path (dist/bundle/, the actual npm/Homebrew/binary install path) since the lazy-provider-loading refactor. The originally reported v0.7.0 release tarball shipped without dist/bundle/amazon-bedrock.js at all (#751, one of the "related reports" under the still-open tracker #1379, Complete CI and release compatibility hardening — "verify the emitted provider bundle closure, including Amazon Bedrock"). The exact same gap still reproduces on current main (06860844e) — confirmed by actually running the build and inspecting the output, not just reading source.

cd packages/coding-agent
rm -rf dist/bundle && node scripts/bundle.mjs
ls dist/bundle | grep -i bedrock   # nothing — every other provider has its own dist/bundle/<name>-<hash>.js chunk

Root cause

packages/ai/src/providers/register-builtins.ts reaches Bedrock through a specifier built at runtime, not a string literal:

const importNodeOnlyProvider = (specifier: string): Promise<unknown> => import(specifier);
...
bedrockProviderModulePromise ||= importNodeOnlyProvider("./amazon-bedrock.js").then(...)

Git history (668ebc094) shows this is deliberate: the specifier is built at runtime (there was even a new Function("specifier", "return import(specifier)") at one point, and a "./amazon-" + "bedrock.js" string split later) specifically so bundlers never eagerly pull @aws-sdk into every build for consumers who never use Bedrock. Every other provider uses a plain import("./provider.js") literal, which esbuild's code splitting can see, split into its own chunk, and rewrite the call site to reference (that's why anthropic-<hash>.js, google-vertex-<hash>.js, etc. all exist and work). Because Bedrock's import is opaque to static analysis, esbuild never bundles the module or its @aws-sdk closure and never emits dist/bundle/amazon-bedrock.js — but the compiled call site still requests exactly that relative path at runtime. First use throws Cannot find module instead of a credentials/config error.

Why the Bun path already works

packages/coding-agent/src/bun/register-bedrock.ts sidesteps this entirely by eagerly, statically importing @earendil-works/pi-ai/bedrock-provider and registering it via setBedrockProviderModule() before startup — fine there because a compiled Bun binary already embeds everything regardless. Doing the same unconditionally for the Node CLI would regress the startup-latency win lazy provider loading was built for (fixes #2297), so the fix keeps loading lazy for Node and instead makes esbuild aware of the module.

Fix

In packages/coding-agent/scripts/bundle.mjs, declare @earendil-works/pi-ai/bedrock-provider (the same static entry point the Bun path already registers) as a second esbuild entry point, resolved via import.meta.resolve and named to the exact literal filename (amazon-bedrock.js, no content hash via esbuild's {in, out} entry point form) the runtime specifier expects:

const bedrockEntry = fileURLToPath(import.meta.resolve("@earendil-works/pi-ai/bedrock-provider"));

await build({
	entryPoints: [
		{ in: join(packageDir, "dist", "cli.js"), out: "cli" },
		{ in: bedrockEntry, out: "amazon-bedrock" },
	],
	...
});

esbuild now compiles and bundles the module and its @aws-sdk dependency closure into that file (~1.3 MB, in line with other bundled providers, e.g. mistral-*.js at ~1.1 MB). Loading stays lazy at runtime: the chunk is only fetched on first actual use of the Bedrock provider, exactly as before.

Also added a post-build check that fails the build if a provider chunk reachable only through a non-literal dynamic import is missing from the output — so a future occurrence of this exact failure mode (silent at build time, only surfacing for a user at first use) fails npm run build, which already runs directly in CI (.github/workflows/ci.yml), instead of shipping. This directly satisfies the "verify the emitted provider bundle closure, including Amazon Bedrock" acceptance criterion tracked in #1379.

Validation

• Before: the repro above shows no amazon-bedrock.js; manually dynamic-importing it from the referencing chunk's own directory throws the exact reported error: Cannot find module '.../dist/bundle/amazon-bedrock.js' imported from .../dist/bundle/chunk-*.js.
• After: the same repro now resolves successfully and returns the expected { bedrockProviderModule } export.
• node scripts/bundle.mjs succeeds; the new closure check passes; dist/bundle/amazon-bedrock.js is emitted.
• npx tsgo -p tsconfig.json --noEmit passes.
• Root npm run check (biome, tsgo --noEmit, installer render, browser smoke) passes.
• Deliberately did not rely on a full root npm run build for validation: its generate-models step does a live network fetch of current provider catalogs and rewrites packages/ai/src/models.generated.ts nondeterministically — unrelated to this change. Confirmed unmodified main also produces this same dirty diff from a plain npm run build, and confirmed tsgo --noEmit passes cleanly on unmodified main without that step, isolating it as pre-existing environment noise rather than something this fix caused.

Patch

Branch: https://github.com/kaluli123123/prime-agent/tree/fix/bundle-amazon-bedrock-chunk-closure

Diff: main...kaluli123123:prime-agent:fix/bundle-amazon-bedrock-chunk-closure

Happy to open a PR from this branch if a maintainer wants to invite implementation, per CONTRIBUTING.md.

[kaluli123123]

Hi @badlogic and @kevinjosethomas,

Could you please vouch/invite @kaluli123123 to contribute this focused fix, or apply it internally?

PR #1874 was automatically closed by the contribution gate because the author was not vouched. The patch addresses the missing
dist/bundle/amazon-bedrock.js runtime chunk. Fresh validation passed: Bedrock exports resolve, npm run check exits 0, and git diff --check passes.

Discussion: #1763
PR: #1874

[dmcOm2024]

Confirmed on the v0.8.1 release tarball (releases/v0.8.1/prime-agent-0.8.1.tgz): dist/bundle/ ships every provider chunk except amazon-bedrock.js, and --provider amazon-bedrock fails at first use with Cannot find module .../dist/bundle/amazon-bedrock.js (imported from the register-builtins chunk). So the gap is not just current main — the latest published release is affected.

One additional data point for the fix: after emitting the missing chunk from the ./bedrock-provider package entry, 0.8.1 still fails with module.streamSimple is not a function — in the published package that entry exports a wrapped bedrockProviderModule object, while the compiled register-builtins destructures top-level streamBedrock/streamSimpleBedrock from the chunk namespace. Bundling dist/providers/amazon-bedrock.js (which exports those two names directly) instead — or aligning the wrapper's exports with what the call site expects — closes it. Validated end-to-end on 0.8.1: with that chunk emitted (esbuild second entry point named to the literal filename, per this discussion's fix), --provider amazon-bedrock completes a real Bedrock request. Would be great to see this land in a release — happy to test a build.

[kaluli123123]

Hi @badlogic and @kevinjosethomas,

Here is a concise contributor profile for @kaluli123123, in case it helps you evaluate a vouch or contributor invitation:

• Focused contribution: investigated the missing amazon-bedrock.js release artifact, documented the reproduction in Discussion Fix: Amazon Bedrock provider still ships broken in the release bundle — missing dist/bundle/amazon-bedrock.js chunk (#751) #1763, and prepared the fix in PR fix(coding-agent): close the Amazon Bedrock bundle runtime entry #1874.
• Delivered patch: commit 7acfae7b721d8e00ef3f1c3779767c44d05fc09b on the kaluli123123/prime-agent fork. It adds the explicit Bedrock bundle entry and validates the emitted runtime chunk.
• Independent validation: npm --prefix packages/coding-agent run bundle passed; the generated module exports streamBedrock and streamSimpleBedrock as functions; npm run check passed; git diff --check passed.
• Process: PRs fix(coding-agent): close the Amazon Bedrock chunk in the release bundle #1784 and fix(coding-agent): close the Amazon Bedrock bundle runtime entry #1874 were closed by the non-vouched contribution gate before technical review. I will not reopen or resubmit them without maintainer invitation or vouching.
• Scope: I am willing to work only on maintainer-invited, focused issues and to follow the repository's development and review rules.

Would you please consider vouching this account or inviting a focused contribution when appropriate? If you prefer another path, I will follow the repository's process.

Thank you for maintaining Prime Agent and for considering this request.

Best,
kaluli123123