Lauren Hirata Singh 3c51d3c5af build: pin Vale once in .mise.toml instead of three times
Vale was pinned in four places with three different versions, so prose could
pass locally and fail in CI:

- `.github/workflows/lint-prose.yml` installed 3.17.1
- `.mise.toml` pinned 3.12.0
- `Makefile` defaulted `VALE_VERSION` to v3.9.6
- `scripts/install-vale.sh` fell back to unpinned `brew install vale` on macOS
  and `jdkato/vale:latest` under Docker

A macOS contributor therefore linted with whatever Homebrew last installed
(3.18.0 on the machine this was found on) while CI gated on 3.17.1.

Make `.mise.toml` the only pin. The Makefile, the install script, and the
workflow now read the version from it, so a bump happens in one place. Keep
3.17.1, the version CI already enforces, so no new violations appear; bumping
the engine is a separate decision.

Also fix two latent bugs in `scripts/install-vale.sh`:

- The release tag carries a "v" prefix but the asset filename does not, and the
  script interpolated the same string into both. With its own v3.9.6 default it
  requested `.../download/v3.9.6/vale_v3.9.6_Linux_64-bit.tar.gz`, which 404s.
  The version is now normalized and the two forms are built separately.
- An existing `.bin/vale` short-circuited the install regardless of its version,
  so a stale binary was never replaced. The script now compares `vale --version`
  against the pin, and reuses a matching binary already on PATH rather than
  downloading a second copy.

The unpinned Homebrew and Docker paths are gone; every platform now gets the
pinned tarball, including macOS on both architectures. The version is read from
a config file and interpolated into a download URL, so it is validated against
a bare-semver pattern first.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-26 15:31:28 -04:00
2025-10-06 16:39:40 -04:00
2025-09-24 17:30:34 -04:00
2026-03-12 08:26:10 -07:00
2025-10-15 10:34:25 -04:00
2025-09-30 19:30:55 +00:00

LangChain Docs

🦜 Welcome! This repository contains the documentation build pipeline for LangChain projects.


Table of contents:


Contribute

To run a local preview of the documentation:

git clone https://github.com/langchain-ai/docs.git
cd docs
make install
make dev

For more information on how to contribute to LangChain documentation, follow the steps outlined in the contributing guide. The contributing guide also explains our documentation types and their writing and quality standards.

For detailed information about setting up your development environment and contributing to documentation, see the documentation contributing guide.

To report issues with reference.langchain.com (missing pages, broken links, or generated API content), open a reference documentation issue on this repo so maintainers can route it.

Reference

Repository structure

# --- docs.langchain.com ----------------------------------------------
build/                    # Built docs (DO NOT EDIT)
packages.yml              # Package metadata (indexes, tables, downloads; not the API reference build)
pipeline/                 # Build pipeline source code
scripts/                  # Helper scripts
src/                      # Source documentation files (< EDIT CONTENT HERE)
    langsmith/            # LangSmith docs
    oss/                  # LangChain, LangGraph, Deep Agents, and integrations docs
    docs.json             # Mintlify site configuration and navigation
tests/                    # Test files for the pipeline
Makefile                  # Build targets
pyproject.toml            # Dependencies

docs.langchain.com

The Mintlify docs pipeline is structured with .mdx source files in /src and build artifacts in /build. Mintlify deploys from the /build folder, which is generated by preprocessing logic.

Important

Never edit /build directly.

The /src/docs.json file is used to configure the Mintlify site navigation and settings. Refer to the Mintlify documentation for detailed syntax and component usage.

Documentation changes follow a PR workflow where all tests must pass before merging. See the contributing guidelines for more details.

reference.langchain.com

API reference is generated and deployed outside this repo. Browse Python and JavaScript/TypeScript reference there. If something is wrong with that site, use the reference docs issue template.

File formats

  • Markdown files (.md, .mdx) - Standard documentation content
  • Snippets (src/snippets/) - Reusable MDX content that can be imported into multiple pages. Important: Snippets undergo special link preprocessing. When writing links in snippets, be careful about path segments.
  • Jupyter notebooks (.ipynb) - Converted to markdown during build, though these are not recommended for new content! Your PR will likely be rejected if you attempt to add a Jupyter notebook unless asked to by a maintainer.
  • Assets - Images and other files are copied to the build directory

Available commands

Make commands:

  • make dev - Start development mode with file watching and live rebuild
  • make build - Build documentation to ./build directory
  • make broken-links - Check for broken links in documentation
  • make broken-links-with-anchors - Check for broken links + check links with anchors
  • make install - Install all dependencies
  • make clean - Remove build artifacts
  • make test - Run the test suite
  • make lint - Check code style and formatting
  • make format - Auto-format code
  • make lint_md - Lint markdown files
  • make lint_md_fix - Lint and fix markdown files
  • make help - Show all available commands

docs CLI tool:

The docs command (installed as uv run docs) provides additional functionality:

  • docs migrate <path> - Convert MkDocs markdown/notebook files to Mintlify format

    • --dry-run - Preview changes without writing files
    • --output <path> - Specify output location (default: in-place)
    • Supports .md, .markdown, .ipynb files
  • docs migrate-docusaurus <path> - Convert Docusaurus markdown/notebook files to Mintlify format

    • --dry-run - Preview changes without writing files
    • --output <path> - Specify output location (default: in-place)
    • Supports .md, .markdown, .mdx, .ipynb files
    • Converts Docusaurus-specific syntax (admonitions, tabs, imports, etc.)
  • docs mv <old_path> <new_path> - Move files and update cross-references

    • --dry-run - Preview changes without moving files

These can be used directly using the Makefile or via the docs CLI tool:

  • docs dev - Start development mode with file watching and hot reload

    • Automatically rebuilds changed files from src/ to build/
    • Launches Mintlify dev server at http://localhost:3000
    • Provides automatic browser refresh when files change
    • --skip-build - Skip initial build and use existing build directory
  • docs build - Build documentation files

    • --watch - Watch for file changes after building

Linting

After running make install, you can use make lint_prose to ensure your writing meets our style guide rules.

make lint_prose installs the Vale version pinned in .mise.toml to .bin/vale, which is the same version the lint-prose CI workflow uses. Bump the pin in .mise.toml only; the Makefile, scripts/install-vale.sh, and the workflow all read it from there. If you already have a different vale on your PATH (from Homebrew, say), the pinned copy in .bin/ takes precedence, so local results match CI.

Codespell

make lint runs uv run codespell src to check source documentation for common spelling errors.

Codespell is configured in pyproject.toml under [tool.codespell]:

  • Add custom accepted words to src/.codespellignore. This file is referenced by ignore-words = "src/.codespellignore".
  • Exclude generated files, vendor content, or other paths that should not be spell checked by adding glob patterns to the skip setting.
  • Keep skip patterns scoped. Prefer adding accepted words to src/.codespellignore when the word is valid documentation content, and use skip when the file or directory should not be checked at all.

You can also follow these steps to enable vale with VS Code or Cursor:

  1. Install the Vale extension (Vale by Chris Chinchilla)
  2. Install Vale CLI: brew install vale (macOS) or see Vale installation for other platforms
  3. Navigate to the Vale extension settings:
    • Set Vale CLI: Config to the absolute path to .vale.ini (in the root of this repo)
    • Set Vale CLI: Min Alert Level to suggestion (many rules are coded as suggestions)

If you cannot use the VS Code UI to configure Vale, add these settings to your settings.json:

    "vale.valeCLI.config": "/path/to/docs/.vale.ini",
    "vale.valeCLI.minAlertLevel": "suggestion"

Note: The extension requires Vale on your PATH. If annotations don't appear (e.g., when Cursor is launched from the Dock), launch Cursor from a terminal so it inherits your PATH, or ensure Homebrew is in your shell profile.

Troubleshooting

General Mintlify errors

In some cases, we use new features that are only available in the latest Mintlify CLI. If you encounter errors, ensure you have the latest version installed:

mint update

# or

npm install -g mint

docs dev not working / running

Re-do the steps to set up your dev environment, ensuring you have activated the virtual environment and installed all dependencies.

Important

Most of the time, mint update solves any docs dev / make dev issues!

Mintlify .venv parsing error

Problem: Running mint broken-links or other Mintlify commands from the project root causes parsing errors like:

Unable to parse .venv/lib/python3.13/site-packages/soupsieve-2.7.dist-info/licenses/LICENSE.md
- 3:48: Unexpected character '@' (U+0040) in name

Root Cause: Mintlify tries to parse all files in the directory, including Python virtual environment files that contain invalid MDX syntax.

Solutions (in order of preference):

  1. Use the safe Make commands (recommended):

    make broken-links-with-anchors      # Builds docs first, then checks internal links
    
  2. Run Mintlify commands from the build directory:

    cd build               # Change to build directory where final docs are
    mint broken-links      # Now safe to run
    

Why this works: The solution ensures Mintlify commands run from the build/ directory where the final documentation is generated, which is the correct place to check for broken links. This avoids scanning the Python virtual environment in the project root.

Prevention: Always use the provided Make commands instead of running raw mint commands from the project root.

Warning: page doesn't exist

If adding a new group, ensure the root index.mdx is included in the pages array like:

{
  "group": "New group",
  "pages": ["new-group/index", "new-group/other-page"]
}

If the trailing /index (no extension included) is omitted, the Mintlify parser will raise a warning even though the site will still build.

S
Description
🦜🔗 Docs for LangChain projects
Readme MIT 1 GiB
Languages
MDX 89.7%
Python 5.9%
TypeScript 2.2%
Kotlin 0.7%
Go 0.4%
Other 1%