LangChain ships provider integrations as separate packages: `@langchain/openai` on npm, `langchain-openai` on pip; one prefix per ecosystem, the vendor name is the suffix.
Think of the way a phone comes with a charging cable in the box but the cable for the next phone you buy lives in a different box. Old LangChain shipped every vendor's cable inside one giant box; you got a working OpenAI cable and 30 cables you would never plug in, plus the weight of all of them. New LangChain ships the core box (the phone) and you grab only the cables you actually need. The npm world labels its cable boxes with an organisation prefix and a slash; the pip world labels its boxes with a hyphen. Same idea, two stickers.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
LangChain's packaging story is one of those topics that sounds like trivia until you have to debug a production install that pulled 400 MB of vendor SDKs into a Lambda function. The packaging split that landed with LangChain 0.1 in early 2024 turned a fat-dependency monolith into a layered architecture, and the per-provider package shape is the externally visible result.
This deep dive walks the history that produced the split, the three-layer architecture, the npm and pip naming conventions, the version-compatibility matrix that the split introduced, the JS/Python parity story, and the architectural implication for vendor portability and ejection cost. By the end you should be able to name the package for any provider in either ecosystem and reason about why mixing versions across the layers can break things.
The pre-split history and why the split happened
Pre-0.1 LangChain (through late 2023) shipped as a single Python package and a single JS package. Inside that package, every vendor integration was an inline module: langchain.chat_models.ChatOpenAI, langchain.chat_models.ChatAnthropic, langchain.embeddings.CohereEmbeddings, and so on. Each module had an optional try: import openai at the top, which meant the IMPORT was lazy but the DEPENDENCY DECLARATION was not.
The consequence was that installing langchain pulled in 20+ provider SDKs as transitive dependencies (via the langchain[all] extras pattern, or via direct requirements pinning in projects that wanted any of them). For a team using only OpenAI, the install size was multiplied 20x over the actual surface they used. Security teams complained because SBOM scans flagged CVEs in SDKs the project never executed. Serverless deployments complained because cold-start install times ballooned. Hexagonal-architecture teams complained because the import graph forced them to vendor code they had not approved.
The LangChain team's response in early 2024 was a hard split into layered packages. The umbrella langchain stayed (for backward compatibility) but the canonical install path became 'one package per provider' plus a small core. The migration was disruptive (every import path changed) but the resulting architecture is what enabled LangChain to keep growing without dragging every adopter into a fat-dependency situation.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- Production Next.js apps using `@langchain/openai` typically also install `@langchain/core` directly to pin the Runnable protocol version.
- Python serverless deploys on AWS Lambda or Cloud Run use `langchain-openai` instead of the umbrella `langchain` to keep cold-start install size under the runtime limits.
What an interviewer would ask next. Try answering before peeking at the approach.
QWhat is in `langchain-core` versus `langchain` versus `langchain-openai`?
langchain-core holds the abstract base classes (BaseChatModel, Runnable, callback protocol). langchain-openai implements ChatOpenAI and OpenAIEmbeddings against core. langchain is a thin umbrella that re-exports common pieces from core plus a few helpers, kept for backward compatibility.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Installing the umbrella `langchain` package and importing `ChatOpenAI` from it. That works through a re-export but pulls extra weight; modern code imports from the provider-specific package directly.
60 second bullets to scan on the way to the call.
The three-layer split: core, per-provider, umbrella
Why the split happened (dependency hygiene, install size)
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.