# LangChain.js: the install line, the workspace scripts, and the packages it defers to

> LangChain.js is the TypeScript framework for chaining LLM components, MIT licensed and installable through npm, pnpm or yarn. This looks at what the install line does not pin, which repository scripts need Docker, and where planning, subagents, monitoring and low level orchestration actually live.

**langchain-ai/langchainjs** — The agent engineering platform

- Repository: https://github.com/langchain-ai/langchainjs
- Website: https://docs.langchain.com/langchain/
- Stars: 18,244 · Forks: 3,406
- Language: TypeScript
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/langchain-ai-langchainjs

## Three package managers, one unpinned package name

The install line is the whole of how you get this code: `npm install -S langchain`, or `pnpm install langchain`, or `yarn add langchain`. Three package managers, one package name, no version, and no flags beyond that. The asymmetry is easy to miss when you copy. Only the npm form carries `-S`; the pnpm and yarn forms are bare, so pasting the npm string into a pnpm or yarn project hands that CLI an argument shape it was not given there. Nothing tells you which manager the project you are joining already uses, and nothing in the install line tells you which release you will land on, because the name is unpinned and resolves to whatever the registry serves at that moment. The contributor side is set up differently. The root package.json is marked `"private": true` under the name langchainjs, and it pins `"packageManager": "pnpm@10.14.0"`. So the package published from this tree is not the package you install, and the workflow used to build the code is not the workflow offered to consumers.

## Node 20, 22 and 24, then a very wide runtime tail

Supported environments are listed as a fixed set rather than a policy, and the Node line is narrower than it first looks: Node.js (ESM and CommonJS) - 20.x, 22.x, 24.x. Odd majors are simply absent. A service pinned to Node 21 or 23 finds no claimed support, and there is no fallback line and no minimum patch guidance, so whether 20.0.0 is early enough is a question the overview does not answer. The rest of the list spreads wide: Cloudflare Workers, Vercel / Next.js (Browser, Serverless and Edge functions), Supabase Edge Functions, Browser, Deno, and Bun. Two of those deserve a second read, because the same import has to work in Node and in a browser bundle where no Node builtins exist. Carrying both module systems at once means you consume it in whichever form your host already uses, and the install line gives you no advice on picking one. A `.nvmrc` file sits at the repo root for contributors, and `deno.json` covers the Deno path, but the version each of those selects is not written down here.

## The root test script needs Docker before it can finish

The scripts block is where the repository's own tooling becomes visible, and it is also where a plain checkout can stall. The test script is not a unit run. It is a unit run chained to a Docker Compose environment test, and that environment test uses `--force-recreate`, so it rebuilds its containers every time. On a machine without a working Docker setup, `pnpm test` gets through the unit half and then fails on the second half no matter how green the first half was. The unit-only escape hatch is `pnpm test:unit`, which is turbo with filters excluding the test-exports packages, `examples`, and `create-langchain-integration`. Around those sit the rest of the toolchain: turbo drives `build`, `watch`, and `clean`; `lint` is `oxlint .`; `format` is `oxfmt .`; releases run through changesets, and the prerelease build sets `BUILD_MODE=prerelease`. The tree also carries `dependency_range_tests/` with its own compose file for the range suite.

```json
"test": "pnpm test:unit && pnpm test:exports:docker",
"test:unit": "turbo test --filter=\"!test-exports-*\" --filter=!examples --filter=!create-langchain-integration",
"test:exports:docker": "docker compose -f environment_tests/docker-compose.yml up --force-recreate",
"test:ranges:docker": "docker compose -f dependency_range_tests/docker-compose.yml up --force-recreate",
"prerelease": "BUILD_MODE=prerelease pnpm build",
"release": "changeset publish"
```

## Planning, subagents and file systems are in Deep Agents instead

The first thing a new user is steered away from is the core package. A tip block near the top of the overview points to Deep Agents, described as a higher-level package built on LangChain for agents that have built-in capabilites for common usage patterns such as planning, subagents, file system usage, and more. The practical consequence is that installing `langchain` gives you none of those three things. Planning, subagents and a file system arrive only when you add a second package, and nothing here states a version pairing between the two, a compatibility range, or an upgrade order. A third package sits further along the same axis: if you are looking for more advanced customization or agent orchestration, the answer given is LangGraph.js, framed as the framework for agents and controllable workflows, with customizable architecture, long-term memory, and human-in-the-loop workflows. So planning-level work, low-level orchestration and the base interface are three installs pointing at three documentation URLs, and the overview does not say which combination a given project needs.

## Monitoring is an integration, so a local install cannot trace your runs

Read the production claim closely and one phrase does most of the work. Deploy reliable applications with built-in support for monitoring, evaluation, and debugging through integrations like LangSmith: the capability arrives through something you integrate, not through something bundled. LangSmith is described as a unified developer platform for building, testing, and monitoring LLM applications, sitting at smith.langchain.com, and LangSmith Deployment is listed separately as a purpose-built platform for long-running, stateful workflows. If a project requirement is being able to look at why a particular run went wrong, the MIT licensed package in your node_modules will not supply it. The trade is a local library for a hosted service, and the terms, pricing and retention rules of that service are not described in this repository. Long-term memory and human-in-the-loop control are credited to LangGraph rather than to the base package, which makes the same point a second time: the base install is deliberately thin.

## Two provider patch releases thirteen hours apart on one morning

Activity here is easy to date, and it is worth dating precisely before adopting any of it. The repository is not archived, and the last push landed 2026-10-01T18:23:06Z, so there is no staleness argument to make. The release list is the more useful signal: langchain@1.5.15 published 2026-10-01T01:15:17Z, then @langchain/xai@1.4.16 at 01:15:41Z, then @langchain/xai@1.4.17 at 14:14:52Z. Two patch releases of the same provider package just under thirteen hours apart, on the same morning as a core release. What that means in practice is concrete. An unpinned install of the provider package can resolve to 1.4.16 or 1.4.17 depending on the hour a CI job happens to run, which makes a lockfile load-bearing in this ecosystem rather than optional hygiene. The version lines also fail to line up: the core package sits at 1.5.x while the xai integration sits at 1.4.x, so any mental model of one shared major version across the ecosystem will be wrong.

## Four things the overview never tells you, and what each one costs

First, no version and no flags. The install line names a package and nothing else, so nothing stops an incompatible major from arriving on an unpinned resolve. Second, no configuration or credential section anywhere in it. The only trace of environment wiring in the tree is `examples/.env.example`, sitting beside `examples/openai_openapi.yaml` and an `examples/hotdog.jpg` used by the example apps, which is a very different thing from a settings reference you can follow. Third, no error handling or troubleshooting section, so what a rejected tool call, a rate limit, or a malformed response looks like in your own logs is undocumented here and has to be found on the docs site. Fourth, model interoperability is offered as a reason to choose the framework, in terms of swapping models in and out as the team experiments, and no migration checklist accompanies it: no note on which call surface changes and no list of what has to be rewritten. That last claim is the one to test against your own code before you restructure anything around it.

## Conclusion

Adopt langchain if you want one interface across model providers and you run Node 20, 22 or 24, and if you accept that planning, subagents and orchestration come from two other packages. Before you commit, check three things yourself: the Node major your host actually runs, whether Docker is present for the full test script, and how your team pays for the LangSmith tracing that your monitoring requirement depends on.

## FAQ

### Is LangChain still used?

The repository is not archived and its last push was 2026-10-01T18:23:06Z, with three releases published that same day, among them langchain@1.5.15.

### What exactly does LangChain do?

It is a framework for building LLM-powered applications that chains together interoperable components and third-party integrations, providing a standard interface for agents, models, embeddings, and vector stores.

### Is LangChain JS available on NPM?

Yes. Three install forms are offered: npm install -S langchain, pnpm install langchain, or yarn add langchain.

### Is LangChain free to use?

The repository is MIT licensed and the package installs from the public registry. The overview separately points to LangSmith as a hosted platform for monitoring, and does not describe that service's terms or pricing.

### langchain vs langchain js

This repository is LangChain.js, the TypeScript build. The Python equivalent is the separate langchain-ai/langchain repository, and low level agent orchestration is pointed at LangGraph.js.

## Sources

- [langchain-ai/langchainjs on GitHub](https://github.com/langchain-ai/langchainjs)
- [License: MIT](https://github.com/langchain-ai/langchainjs/blob/main/LICENSE)
- [Project website](https://docs.langchain.com/langchain/)
- [README](https://github.com/langchain-ai/langchainjs/blob/main/README.md)
- [Releases](https://github.com/langchain-ai/langchainjs/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/langchain-ai-langchainjs