Skip to main content

Contributing to code

还没翻译译自英文(docs.langchain.com)本页 132 段都还没译

Code contributions are welcome! Whether you're fixing bugs, adding features, or improving performance, your contributions help deliver a better developer experience for thousands of developers.

Getting started

If you are looking for something to work on, check out the issue labeled "help wanted" in our repos:

Note

Before submitting large new features or refactors, please first open an issue or post to the forum for discussion. This ensures alignment with project goals and prevents duplicate work.

Quick fix: submit a bugfix

For simple bugfixes, you can get started immediately:

  1. Reproduce the issue

    Before even cloning the repository, ensure you can reliably reproduce the bug. This helps confirm the issue and provides a starting point for your fix. Maintainers and other contributors should be able to reproduce the issue based on your description without additional setup or modifications.

  2. Fork the repository

    Fork either the LangChain, LangGraph, or Deep Agents repo to your personal GitHub account

  3. Clone and setup

    git clone https://github.com/your-username/name-of-forked-repo.git
    
    # For instance, for LangChain:
    git clone https://github.com/parrot123/langchain.git

    Warning

    The LangChain Python repo is a monorepo — there is no pyproject.toml at the repo root. Each package has its own under libs/ (e.g. libs/core/, libs/langchain/, libs/partners/openai/). You must cd into the relevant package directory before running uv commands.

    # Navigate into the package you want to work on, then install dependencies
    cd libs/core          # or libs/langchain, libs/partners/openai, etc.
    uv sync --all-groups
    
    # or, to install a specific group only:
    uv sync --group test

    You will need to install uv if you haven't previously. See the repository structure section for a full list of packages and their locations.

  4. Create a branch

    Create a new branch for your fix. This helps keep your changes organized and makes it easier to submit a pull request later.

    git checkout -b your-username/short-bugfix-name
  5. Write failing tests

    Add unit tests that will fail without your fix. This allows us to verify the bug is resolved and prevents regressions

  6. Make your changes

    Fix the bug while following our code quality standards. Make the minimal change necessary to resolve the issue. We strongly encourage contributors to comment on the issue before they start coding. For example:

    "I'd like to work on this. My intended approach would be to [...brief description...]. Does this align with maintainer expectations?"

    A 30-second comment often prevents wasted effort if your initial approach is wrong.

  7. Verify the fix

    Ensure that tests pass and no regressions are introduced. Ensure all tests pass locally before submitting your PR

    make format
    make lint
    make test
    
    # For bugfixes involving integrations, also run:
    make integration_tests
    # (You may need to set up API testing credentials)
  8. Document the change

    Update docstrings and/or inline comments if behavior changes

  9. Submit a pull request

    Follow the PR template provided. If applicable, reference the issue you're fixing using a closing keyword (e.g. Fixes #ISSUE_NUMBER) so that the issue is automatically closed when your PR is merged.

Full development setup

For ongoing development or larger contributions:

  1. Review our contribution guidelines for features, bugfixes, and integrations
  2. Set up your environment following our setup guide below
  3. Understand the repository structure and package organization
  4. Learn our development workflow including testing and linting

Contribution guidelines

Before you start contributing to LangChain projects, take a moment to think about why you want to. If your only goal is to add a "first contribution" to your resume (or if you're just looking for a quick win) you might be better off doing a boot-camp or an online tutorial.

Contributing to open source projects takes time and effort, but it can also help you become a better developer and learn new skills. However, it's important to know that it might be harder and slower than following a training course. That said, contributing to open source is worth it if you're willing to take the time to do things well!

Backwards compatibility

Warning

Breaking changes to public APIs are not allowed except for critical security fixes.

See our versioning policy for details on major version releases.

Maintain compatibility via:

New features

We aim to keep the bar high for new features. We generally don't accept new core abstractions from outside contributors without an existing issue that demonstrates an acute need for them. This also applies to changes to infrastructure and dependencies.

In general, feature contribution requirements include:

  1. Design discussion

    Open an issue describing:

    • The problem you're solving
    • Proposed API design
    • Expected usage patterns
  2. Implementation

    • Follow existing code patterns
    • Include comprehensive tests and documentation
    • Consider security implications
  3. Integration considerations

    • How does this interact with existing features?
    • Are there performance implications?
    • Does this introduce new dependencies?

    We will reject features that are likely to lead to security vulnerabilities or reports.

Security guidelines

Warning

Security is paramount. Never introduce vulnerabilities or unsafe patterns.

Security checklist:


Development environment

Tip

Using an AI coding agent?

  • Install the LangChain Docs MCP servers to give your agent access to up-to-date LangChain documentation and examples.

    Connect LangChain docs MCP servers

    Connect both LangChain documentation MCP servers to my coding agent so it can look up current LangChain, LangGraph, and LangSmith docs and API reference.

    Servers to add:

    Detect which agent or editor I am using (Claude Code, Cursor, Codex CLI, Claude Desktop, Deep Agents Code, VS Code, Antigravity, or another MCP-compatible client). Use the matching setup from https://docs.langchain.com/use-these-docs.md:

    • Claude Code: claude mcp add --transport http for each server (project scope by default; use --scope user only if I ask for global access).
    • Codex CLI: codex mcp add with each server URL.
    • Cursor, Deep Agents Code, VS Code, or Antigravity: merge both entries into the MCP settings JSON using the field names shown on that page for my client.
    • Claude Desktop: add both URLs under Settings > Connectors.

    Do not invent alternate MCP URLs. After configuring, confirm both servers are listed and reachable.

  • Install LangChain Skills to improve your agent's performance on LangChain ecosystem tasks, then click the Copy page button on the top right of this page and paste the raw content into your agent to have it set up your environment automatically.

    Install LangChain Skills

    Install LangChain Skills for my coding agent so it can perform better on LangChain, LangGraph, and Deep Agents tasks.

    Use the Agent Skills installer from https://github.com/langchain-ai/langchain-skills:

    npx skills add langchain-ai/langchain-skills --skill '*' --yes

    If I ask for a global install instead, use:

    npx skills add langchain-ai/langchain-skills --skill '*' --yes --global

    Detect which agent or editor I am using. If I use Claude Code and prefer the plugin path, follow the marketplace install from that repository README (/plugin marketplace add then /plugin install). Do not invent alternate skill package names or install URLs. After installing, confirm the skills are available to the agent.

Our Python projects use uv for dependency management. Make sure you have the latest version installed.

Info

We strive to keep setup consistent across all Python packages. From the package directory, run:

uv sync --all-groups
make test  # Verify unit tests pass before starting development

Once you've reviewed the contribution guidelines, find the package directory for the component you're working on in the repository structure section below.


Repository structure

LangChain is organized as a monorepo with multiple packages:

  • langchain (located in libs/langchain/): Main package with chains, agents, and retrieval logic
  • langchain-core (located in libs/core/): Base interfaces and core abstractions

LangGraph is organized as a monorepo with multiple Python packages:

  • langgraph (located in libs/langgraph/): Core framework for building stateful, multi-actor agents
  • langgraph-prebuilt (located in libs/prebuilt/): High-level APIs for creating and running agents and tools

Deep Agents is organized as a monorepo with multiple Python packages:

  • deepagents (located in libs/deepagents/): Core framework for building deep agents with planning, filesystem, and subagent capabilities
  • deepagents-code (located in libs/code/): Deep Agents Code — interactive terminal interface with conversation resume, web search, and sandboxes
  • deepagents-cli (located in libs/cli/): Deploy tooling (deepagents deploy, deepagents init, deepagents dev) for shipping agents to LangSmith Deployments


Development workflow

Pre-commit hooks

The LangChain and Deep Agents repositories include pre-commit hooks that automatically run formatting, linting, and validation checks before each commit. Install them from the repository root:

pip install pre-commit  # or: uv tool install pre-commit
pre-commit install

The hooks enforce:

  • No direct commits to protected branches
  • YAML and TOML syntax validation
  • Trailing whitespace and end-of-file fixes
  • Smart quote and non-standard space normalization
  • Per-package make format and make lint

Running tests

Info

Directories are relative to the package you're working in.

We favor unit tests over integration tests when possible. Unit tests run on every pull request, so they should be fast and reliable. Integration tests run on a schedule and require more setup, so they should be reserved for confirming interface points with external services.

Unit tests

Location: tests/unit_tests/

Unit tests cover modular logic that does not require calls to outside APIs. If you add new logic, you should add a unit test. In unit tests, check pre/post processing and mock external dependencies.

Requirements:

  • No network calls allowed
  • Test all code paths including edge cases
  • Use mocks for external dependencies

To run unit tests:

make test

# Or directly:
uv run --group test pytest tests/unit_tests

# To run a specific test:
TEST_FILE=tests/unit_tests/test_imports.py make test

Integration tests

Location: tests/integration_tests/

Integration tests cover logic that requires making calls to outside APIs (often integration with other services).

Integration tests require access to external services/provider APIs (which can cost money) and therefore are not run by default.

Not every code change will require an integration test, but keep in mind that we'll require/run integration tests separately as part of our review process.

Requirements:

  • Test real integrations with external services
  • Use environment variables for API keys
  • Skip gracefully if credentials unavailable

To run integration tests:

make integration_tests

# Or directly:
uv run --group test --group test_integration pytest --retries 3 --retry-delay 1 tests/integration_tests

# To run a specific test:
TEST_FILE=tests/integration_tests/test_openai.py make integration_tests

Code quality standards

Contributions must adhere to the following quality requirements:

Required: Complete type annotations for all functions

def process_documents(
    docs: list[Document],
    processor: DocumentProcessor,
    *,
    batch_size: int = 100
) -> ProcessingResult:
    """Process documents in batches.

    Args:
        docs: List of documents to process.
        processor: Document processing instance.
        batch_size: Number of documents per batch.

    Returns:
        Processing results with success/failure counts.
    """

Required: Google-style docstrings for all public functions.

Guiding principle: Docstrings describe "what"; docs on this site explain the "how" and "why."

Content typeLocationPurpose
Parameter typesSignatureAuto-generates into API reference
Parameter descriptionsDocstringsAuto-generates into API reference
Return types and exceptionsDocstringsAPI reference
Minimal usage exampleDocstringsShow basic instantiation pattern
Feature tutorialsThis siteIn-depth walkthroughs
End-to-end examplesThis siteReal-world usage patterns
Conceptual explanationsThis siteUnderstanding and context

Docstrings should contain:

  1. One-line summary of what the class/function does
  2. Link to this site for tutorials, guides, and usage patterns
  3. Parameter documentation with types and descriptions
  4. Return value description
  5. Exceptions that may be raised
  6. Single minimal example showing basic instantiation/usage as necessary

Automated: Formatting and linting via ruff

make format  # Apply formatting
make lint    # Check style and types

Standards:

  • Descriptive variable names
  • Break up complex functions (aim for fewer than 20 lines)
  • Follow existing patterns in the codebase

Dependencies

LangChain packages distinguish between hard dependencies and optional dependencies to keep packages lightweight and minimize installation overhead for users.

Almost all new dependencies should be optional. Use optional dependencies when:

  • The dependency is only needed for specific integrations or features
  • Users can meaningfully use the package without this dependency
  • The dependency is large or has many transitive dependencies

Requirements:

  • Users without the dependency installed must be able to import your code without any side effects (no warnings, no errors, no exceptions)
  • pyproject.toml and uv.lock are not modified

To add an optional dependency:

  1. Add the dependency to the appropriate testing dependencies file (e.g., extended_testing_deps.txt)
  2. Add a unit test that at minimum attempts to import the new code. Ideally, the unit test uses lightweight fixtures to test the logic of the code.
  3. Use the @pytest.mark.requires("package_name") decorator for any unit tests that require the dependency.

Hard dependencies are installed automatically when users install the package. Use hard dependencies only when:

  • The package fundamentally cannot function without the dependency
  • The dependency is small and has minimal transitive dependencies
  • There is no reasonable way to make the functionality optional

Warning

Adding hard dependencies increases install time and potential version conflicts for all users.

Maintainers will scrutinize hard dependency additions carefully!

To add a hard dependency:

  1. Open an issue or discussion explaining why the dependency must be hard rather than optional
  2. Add the dependency to pyproject.toml under the appropriate section
  3. Run uv lock to update the lockfile
  4. Include comprehensive tests covering the new functionality

Test writing guidelines

In order to write effective tests, there's a few good practices to follow:

  • Use natural language to describe the test in docstrings
  • Use descriptive variable names
  • Be exhaustive with assertions
def test_document_processor_handles_empty_input():
    """Test processor gracefully handles empty document list."""
    processor = DocumentProcessor()

    result = processor.process([])

    assert result.success
    assert result.processed_count == 0
    assert len(result.errors) == 0
@pytest.mark.requires("openai")
def test_openai_chat_integration():
    """Test OpenAI chat integration with real API."""

    chat = ChatOpenAI()
    response = chat.invoke("Hello")

    assert isinstance(response.content, str)
    assert len(response.content) > 0
def test_retry_mechanism(mocker):
    """Test retry mechanism handles transient failures."""
    mock_client = mocker.Mock()
    mock_client.call.side_effect = [
        ConnectionError("Temporary failure"),
        {"result": "success"}
    ]

    service = APIService(client=mock_client)
    result = service.call_with_retry()

    assert result["result"] == "success"
    assert mock_client.call.call_count == 2

Submitting your PR

Once your tests pass and code meets quality standards:

  1. Push your branch and open a pull request
  2. Follow the provided PR template
  3. Reference related issues using a closing keyword (e.g., Fixes #123)
  4. Wait for CI checks to complete

Note

If your PR includes AI-generated content, you must follow our acceptable uses of LLMs policy. PRs that appear to be low-effort, AI-generated spam will be closed without comment.

Warning

Address CI failures promptly. Maintainers may close PRs that do not pass CI within a reasonable timeframe.

Getting help

Our goal is to have the most accessible developer setup possible. Should you experience any difficulty getting setup, please ask in the community slack or open a forum post.

Check

You're now ready to contribute high-quality code to LangChain!