[tonytrinh3]

Summary

Plain version: The other LaunchDarkly JavaScript SDKs already ship in two module formats. This AI SDK did not. It shipped ESM only, so old CommonJS projects crashed when they loaded it. This PR gives the AI SDK the same two-format build, so those projects work.

What it means for the code (junior eng): The other JavaScript SDKs live in launchdarkly/js-core. They build with tsup and publish both an import condition and a require condition. The AI SDK was the outlier with no require condition. Now every @launchdarkly/ai-* package builds with tsup and emits dist/index.js (ESM) and dist/index.cjs (CommonJS). So require('@launchdarkly/ai-node') works. A Webpack bundle that keeps the packages external also works. Node no longer throws ERR_PACKAGE_PATH_NOT_EXPORTED.

Closes AIC-3415. This fixes the failure in AIC-3370.

Which AIC-3370 asks this PR answers

Plain version: This PR answers ask 1 in full. It also adds a few rows to the support table in the root README, which is part of ask 4. The other asks belong to other PRs.

What it means for the code (junior eng): Ask 1 wants a CommonJS-compatible conditional export. The evidence sits in this diff.

• Nine packages now build both formats: client, ai-node, ai-otel, claude-agents, claude-messages, openai-agents, openai-messages, langchain-agents, and langchain-messages.
• Each exports map gains a require branch:

".": {
  "import": { "types": "./dist/index.d.ts", "default": "./dist/index.js" },
  "require": { "types": "./dist/index.d.cts", "default": "./dist/index.cjs" }
}

• In integration-tests/commonjs-webpack/commonjs-webpack.test.ts, the externalized case flips from an expected failure to an expected success. The suite also adds a require() consumer and an import consumer that run from packed tarballs on Node 22 and Node 24.

Ask 4 wants a support matrix. PR #76 owns that matrix. This PR only updates its rows in the root README, because five load paths now work instead of three. It adds no new bundler and no new row.

Asks 2 and 4 belong to PR #76. Ask 3 belongs to PR #76 plus PR #79. Ask 5 belongs to PR #78.

Changes

• This PR adopts the build that js-core already uses. 11 js-core packages build with tsup, and 23 of its 32 packages publish a require condition. The AI SDK published none, so it was the outlier.
• Nine packages move from tsc to tsup-node. They share one config at tsup.config.base.ts.
• Each exports map gets a require condition. It points to dist/index.cjs and dist/index.d.cts. The fields main, module, and types stay aligned for old tools.
• The externalized test case from PR1 now expects success. The suite also adds require() and import consumers, tarball checks, and manifest checks.
• The CJS output keeps optional dependencies behind a runtime import(). So users still choose to install OpenTelemetry, LangChain providers, and @launchdarkly/node-server-sdk.
• The integration job in CI now runs on Node 22 and Node 24.

Implementation details

The build

Each package holds one line of config:

export { default } from '../../tsup.config.base';

The shared config is small:

// tsup.config.base.ts
export default defineConfig({
  entry: { index: 'src/index.ts' },
  format: ['esm', 'cjs'],
  splitting: false,
  sourcemap: true,
  clean: true,
  dts: true,
});

The scripts prepare, build, and build:watch call tsup-node.

Consistency with js-core

This PR adds no new pattern. It copies the current js-core build.

• The config in packages/sdk/server-ai/tsup.config.ts matches the config here field for field: the same entry, the same two formats, splitting: false, sourcemaps, clean output, and declarations.
• The manifest shape matches too. The field main points to the .cjs file. The field module points to the .js file. The exports map holds a require branch and an import branch, and each branch names its own declaration file.
• Two cosmetic differences remain. js-core lists require before import. Our legacy fields omit the leading ./. Node matches conditions by name and not by order, so neither difference changes behavior.

Bundler coverage

CI proves one bundler: Webpack 5 with webpack-node-externals. That tool produced the incident, so it comes first. A require condition is the standard mechanism, so esbuild, Rollup, and Vite should now work too. I did not test them, so the README does not claim them.

Optional dependencies

esbuild keeps await import('...') of an external package as a real dynamic import in the CJS file. A static require would force users to install every optional package. The test suite reads each dist/index.cjs. It asserts the file contains import("@launchdarkly/node-server-sdk"). It asserts the file does not contain require("@launchdarkly/node-server-sdk").

TypeScript project layout

The declaration build reads files outside the old glob src/*.ts. That broke the composite project build with error TS6307. Each package tsconfig.json drops composite. A new file tsconfig.ref.json holds composite: true and include: ["src/**/*"]. The root tsconfig.json points at those files. The root build and clean scripts now call workspace scripts. The build runs @launchdarkly/ai-server first, because the handler packages read types from its dist folder.

Alternatives that I rejected

A second tsc pass plus a dist/package.json shim adds more moving parts. It also produces no .d.cts file. A custom esbuild wrapper repeats what tsup already does. js-core already uses tsup.

Scope

I changed no source imports and no runtime logic. The package @launchdarkly/ai-node stays a pure barrel. I updated the READMEs, because CommonJS is now supported.

Testing

These commands pass: yarn build, yarn typecheck, yarn code:check, yarn lint:pkg, and yarn test. I ran npm pack --dry-run for all nine packages. Each tarball holds dist/index.js, dist/index.cjs, dist/index.d.ts, and dist/index.d.cts. The command yarn test:integration passes 21 of 21 tests on Node 22.23.2 and on Node 24.16.0. That run covers the externalized case, the allowlisted case, and the require and import consumers.

Link to Devin session: https://app.devin.ai/sessions/c730a69bf9534f648dd5cb5f1db6a28b
Open in Devin Desktop: https://app.devin.ai/desktop/session/c730a69bf9534f648dd5cb5f1db6a28b?variant=devin
Requested by: @tonytrinh3

---

Note

Overview
Adds CommonJS publishing across the AI SDK so require(), Webpack externalized bundles, and plain CJS/ESM consumers resolve published packages instead of hitting ERR_PACKAGE_PATH_NOT_EXPORTED (AIC-3370).

All nine publishable workspaces switch from tsc to shared tsup (tsup.config.base.ts), emitting dist/index.js + dist/index.cjs and matching index.d.ts / index.d.cts. Each package.json gains a require branch in exports and sets main to the CJS file. Root build/clean run workspace scripts ( @launchdarkly/ai-server first ); TypeScript composite moves to tsconfig.ref.json per package.

Integration tests and CI flip the Webpack externalized case to expect success, add entrypoints.cjs / entrypoints.mjs, tarball/manifest checks, and assertions that optional peers stay on runtime import() in CJS. The CommonJS/Webpack job runs on Node 22 and 24. READMEs document dual-format support and updated load-path matrix.

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

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

@cursor review

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

[devin-ai-integration]

Pre-merge verification on packed artifacts

Plain version: I built the packages the way npm would publish them. I installed them into two empty projects. One project is CommonJS. One project is ESM. Both loaded every package, with require and with import, on Node 22 and Node 24. Types work too.

One risk stays, and it does not block this PR. If one app loads the same package both ways, Node loads two copies of it. Two copies mean two clients and two telemetry setups. Every package that ships both formats has this behavior. It only affects an app that mixes require and import for the same package.

What it means for the code (junior eng): What I ran, against npm pack tarballs and not workspace links:

• require() and await import() of all nine packages, from a CommonJS consumer and an ESM consumer, on Node 22 and Node 24. Every package resolved. @launchdarkly/ai-otel exports nothing by design.
• tsc with module: node16, moduleResolution: node16, and skipLibCheck: false, from a .cts file and from a .mts file. No errors. Every tarball ships dist/index.js, dist/index.cjs, dist/index.d.ts, and dist/index.d.cts.
• The optional dependencies stay behind a real import() in dist/index.cjs. tsup did not inline them, so the OTel and node-server-sdk discovery path still works from CommonJS.

The dual-copy case, measured in a CommonJS consumer:

require('@launchdarkly/ai-server').NativeTool === (await import('@launchdarkly/ai-server')).NativeTool;
// false

So instanceof NativeTool fails across the two copies, and initClient() state is not shared between them. The fix for a consumer is one load style per package. I can add that line to the README here, or open a follow-up ticket for it.