feat: Bump to LangChain 1.0 and drop community package requirement

[epietrowicz]

This change bumps @langchain/community to the current npm release line and aligns @langchain/core, langchain, and @traceloop/instrumentation-langchain so peer dependencies resolve cleanly. It also adjusts token usage typing for LangChain 1.x response metadata.

Made with Cursor

---

Note

Medium Risk
Dependency upgrades to LangChain v1 and instrumentation packages may introduce runtime/typing incompatibilities for consumers. Metrics extraction now relies on usage_metadata, so token counts could change or be missing depending on provider support.

Overview
Upgrades @launchdarkly/server-sdk-ai-langchain to LangChain v1 by bumping langchain, @langchain/core, and @traceloop/instrumentation-langchain, and drops @langchain/community as a direct/peer dependency.

Updates LangChainProvider.getAIMetricsFromResponse (and its tests) to read token usage from LangChain v1’s AIMessage.usage_metadata (*_tokens fields) instead of the older response_metadata.tokenUsage shape.

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

[jsonbailey]

Thanks for digging into this and opening the PR! The root cause you identified is real — the transitive @langchain/community → @browserbasehq/stagehand → dotenv@^16.4.5 chain does cause the ERESOLVE conflict. After reviewing this more deeply we made a couple of adjustments and pushed them onto your branch.

What we changed and why:

1. Removed @langchain/community entirely (from both devDependencies and peerDependencies).

   We traced back through the git history and found that @langchain/community was added speculatively during an ESM migration refactor — no source or test file actually imports it. Our provider only uses @langchain/core (for BaseChatModel and message types) and langchain (for initChatModel). While initChatModel can dynamically load community-based providers at runtime, that's the user's responsibility — they'll install whichever provider package they need. Keeping @langchain/community as a peer dep imposed its entire transitive dependency tree (including stagehand) on every user, even those who never touch a community model.

   Dropping it is the correct fix here — bumping to 1.x alone wouldn't have resolved the conflict anyway, since @langchain/community@1.x still pins @browserbasehq/stagehand@^1.0.0, and every stagehand 1.x release requires dotenv@^16.4.5.

2. Restricted all remaining langchain peer deps to 1.x only (@langchain/core, langchain, @traceloop/instrumentation-langchain).

   Your instinct to bump to 1.x was right. We went a step further and dropped the ^0.2.0 || ^0.3.0 fallback ranges entirely — there's no benefit to maintaining compatibility with pre-1.0 versions going forward.

3. Kept your LangChainProvider.ts type cast for tokenUsage — that's a valid fix for 1.x's stricter response_metadata typing.

Thanks again for the contribution!

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Reviewed by Cursor Bugbot for commit a849c6f. Configure here.}