@langchain/core 1.1.25 adds a LangChainError base class, which ModelAbortError now extends alongside a new ContextOverflowError for context window overflows. Alongside it, addLangChainErrorFields in @langchain/core/errors gains a @deprecated marker pointing readers at subclassing LangChainError instead. The function keeps its signature and keeps working; only its declaration file changed.
What changed
addLangChainErrorFieldsis deprecated, not removed. Its declaration in@langchain/core/errorsnow carries@deprecated Subclass LangChainError instead. Emendant reports each import of it from that module, so you can find every call site before the function is removed in a later major.
Before and after
A call built through the deprecated helper, with the import held in a variable-free form that the matcher attributes directly:
import { addLangChainErrorFields } from '@langchain/core/errors';
export function makeAuthError(err: unknown) { return addLangChainErrorFields(err, 'MODEL_AUTHENTICATION');}No transform writes this one: turning a function call into a subclass changes the shape of the value, not just its name. The entry carries an assisted fix instead, and a decline is the likely answer for the same reason. The declaration file’s own pattern, the one ModelAbortError and ContextOverflowError both follow, is to extend LangChainError directly:
import { LangChainError } from '@langchain/core/errors';
class ModelAuthenticationError extends LangChainError { readonly name = 'ModelAuthenticationError';}The matcher is precise about the name it is looking for, not the local one it is bound to. An import of ContextOverflowError renamed on the way in to addLangChainErrorFields is not a use of the deprecated function, and Emendant does not report it.
Migration guidance and its limits
This entry carries an assisted fix. Naming a model provider on the command line or in emendant.json lets fix try it, and without one the finding is reported with its guidance and nothing is sent anywhere. Do not count on a patch. The name is deprecated rather than removed and still works, so the guidance asks for a rewrite only where the release names a direct replacement with the same behaviour, and subclassing is a different shape rather than a new spelling.
What you still have to decide: whether each call site is worth converting to a LangChainError subclass now, or left until the function is actually removed. The declaration file does not say when that will be, only that it will happen.
A clean scan does not tell you that your own error handling already expects the fields addLangChainErrorFields attaches to a plain object rather than the properties a LangChainError subclass exposes on an instance. Check anywhere your code inspects the error it gets back, including logging and serialisation, before you rewrite a call site.
The matcher only follows the imported name addLangChainErrorFields from @langchain/core/errors. A reimplementation, a copy pasted version, or a call reached through a re-export from your own module is not something this entry can see.
What Emendant detects, fixes and verifies
1 change in @langchain/core 1.1.25. 0 patched by a transform, 1 patched only with a model provider you name, 0 report only. Every patch is proved in a copy of your repository before it is offered, and its header names the checks that passed. This table is generated from the feed entry, so it cannot claim more than the entry does.
| Change | Severity | Detects | Fix | Verified by |
|---|---|---|---|---|
Deprecated addLangChainErrorFieldslangchain-core-npm-1.1.25-errors-add-lang-chain-error-fields-deprecated | Deprecation |
| Patch, only when you name a model provider | Your typecheck and tests |
emendant explain <change-id> prints any row's entry, guidance and sources at the terminal.
Coverage
- Snapshot
2026-09-20.1, sequence 27, signed 20 September 2026- Minimum CLI
emendant@0.1.0- Feed entry
feed/npm/@langchain/core/1.1.25.json
emendant feed status shows the snapshot your machine holds, and emendant feed update fetches the latest.
Primary sources
Every claim above was checked against these, each pinned to the release rather than to a default branch.
- @langchain/core@1.1.25npm registry, the published package
- @langchain/core@1.1.24npm registry, the published package
Scan your repository
Runs locally, reads your lockfile and source, sends nothing anywhere.
npx emendant scanThen npx emendant fix writes the patches the table says exist. The getting started guide covers the flags and the patch grades.