始终欢迎代码贡献！无论您是修复错误、添加功能还是提高性能，您的贡献都有助于为数千名开发者提供更好的开发体验。
在提交大型新功能或重构之前，请先在论坛中讨论您的想法。这确保与项目目标保持一致，并防止重复工作。这不适用于错误修复或小改进，您可以直接通过拉取请求贡献。请务必在 PR 描述中链接任何相关问题。使用以在合并 PR 时自动关闭问题。新集成应遵循集成指南。

​
理念

旨在为所有代码贡献遵循这些核心原则：

向后兼容性

维护稳定的公共接口并避免破坏性更改

测试优先

每个更改都必须包含全面的测试以验证正确性并防止回归

代码质量

遵循一致的风格、文档和架构模式

安全为重

优先考虑安全编码实践和漏洞预防

​
入门

​
快速修复：提交错误修复

对于简单的错误修复，您可以立即开始：
1

分叉仓库

将 LangChain 或 LangGraph 仓库分叉到您的
2

克隆和设置

git clone https://github.com/your-username/name-of-forked-repo.git

# For instance, for LangChain:
git clone https://github.com/parrot123/langchain.git

# For LangGraph:
git clone https://github.com/parrot123/langgraph.git

# Inside your repo, install dependencies
uv sync --all-groups
You will need to install uv if you haven’t previously.
3

Create a branch

git checkout -b your-username/short-bugfix-name
4

Make your changes

Fix the bug while following our code quality standards
5

Add tests

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

Run tests

Ensure all tests pass locally before submitting your PR
make lint
make test

# For bugfixes involving integrations, also run:
make integration_tests
7

Submit a pull request

Follow the PR template provided. If applicable, reference the issue you’re fixing using a closing keyword (e.g. Fixes #123).

​
Full development setup

For ongoing development or larger contributions:
1

Development environment

Set up your environment following our setup guide below
2

Repository structure

Understand the repository structure and package organization
3

Development workflow

Learn our development workflow including testing and linting
4

Contribution guidelines

Review our contribution guidelines for features, bugfixes, and integrations

​
Development environment

Our Python projects use uv for dependency management. Make sure you have the latest version installed.
Set up a development environment for the package(s) you’re working on.
  • LangChain
  • LangGraph
For changes to langchain-core:
cd libs/core
uv sync --all-groups
make test  # Ensure tests pass before starting development
For changes to langchain:
cd libs/langchain
uv sync --all-groups
make test  # Ensure tests pass before starting development
For changes to partner integrations:
cd libs/partners/langchain-{partner}
uv sync --all-groups
make test  # Ensure tests pass before starting development
For changes to community integrations (located in a separate repo):
cd libs/community/langchain_community/path/to/integration
uv sync --all-groups
make test  # Ensure tests pass before starting development

​
Repository structure

  • LangChain
  • LangGraph
LangChain is organized as a monorepo with multiple packages:

Core 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
Located in libs/partners/, these are independently versioned packages for specific integrations. For example:Many partner packages are in external repositories. Please check the list of integrations for details.

​
Development workflow

​
Testing requirements

Directories are relative to the package you’re working in.
Every code change must include comprehensive tests.
1

Unit tests

Location: tests/unit_tests/Requirements:
  • No network calls allowed
  • Test all code paths including edge cases
  • Use mocks for external dependencies
make test
# Or directly:
uv run --group test pytest tests/unit_tests
2

Integration tests

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 apart of our review process.Location: tests/integration_tests/Requirements:
  • Test real integrations with external services
  • Use environment variables for API keys
  • Skip gracefully if credentials unavailable
make integration_tests
3

Test quality checklist

  • Tests fail when your code is broken
  • Edge cases and error conditions are tested
  • Proper use of fixtures and mocks

​
Code quality standards

Quality requirements:
  • Type hints
  • Documentation
  • Code style
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.
    """

​
Manual formatting and linting

Code formatting and linting are enforced via CI/CD. Run these commands before committing to ensure your code passes checks.
Run formatting and linting:
1

Format code

make format
2

Run linting checks

make lint
3

Verify changes

Both commands will show you any formatting or linting issues that need to be addressed before committing.

​
Contribution guidelines

​
Backwards compatibility

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:
Always preserve:
  • Function signatures and parameter names
  • Class interfaces and method names
  • Return value structure and types
  • Import paths for public APIs
Acceptable modifications:
  • Adding new optional parameters
  • Adding new methods to classes
  • Improving performance without changing behavior
  • Adding new modules or functions
  • Would this break existing user code?
  • Check if your target is public
  • If needed, is it exported in __init__.py?
  • Are there existing usage patterns in tests?

​
Bugfixes

For bugfix contributions:
1

Reproduce the issue

Create a minimal test case that demonstrates the bug. Maintainers and other contributors should be able to run this test and see the failure without additional setup or modification
2

Write failing tests

Add unit tests that would fail without your fix
3

Implement the fix

Make the minimal change necessary to resolve the issue
4

Verify the fix

Ensure that tests pass and no regressions are introduced
5

Document the change

Update docstrings if behavior changes, add comments for complex logic

​
New features

We aim to keep the bar high for new features. We generally don’t accept new core abstractions, changes to infra, changes to dependencies, or new agents/chains from outside contributors without an existing issue that demonstrates an acute need for them. 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

Security is paramount. Never introduce vulnerabilities or unsafe patterns.
Security checklist:
  • Validate and sanitize all user inputs
  • Properly escape data in templates and queries
  • Never use eval(), exec(), or pickle on user data, as this can lead to arbitrary code execution vulnerabilities
  • Use specific exception types
  • Don’t expose sensitive information in error messages
  • Implement proper resource cleanup
  • Avoid adding hard dependencies
  • Keep optional dependencies minimal
  • Review third-party packages for security issues

​
测试与验证

​
本地运行测试

在提交 PR 之前，请确保完成以下步骤。请注意，LangChain 与 LangGraph 的要求略有差异。
  • LangChain
  • LangGraph
1

Unit tests

make test
All unit tests must pass
2

Integration tests

make integration_tests
(Run if your changes affect integrations)
3

Formatting

make format
make lint
Code must pass all style checks
4

Type checking

make type_check
All type hints must be valid
5

PR submission

Push your branch and open a pull request. Follow the provided form template. Note related issues using a closing keyword. After submitting, wait, and check to ensure the CI checks pass. If any checks fail, address the issues promptly - maintainers may close PRs that do not pass CI within a reasonable timeframe.

​
测试编写指南

为了编写有效的测试，需要遵循一些良好的实践：
  • Use natural language to describe the test in docstrings
  • Use descriptive variable names
  • Be exhaustive with assertions
  • Unit tests
  • Integration tests
  • Mock usage
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

​
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.
You’re now ready to contribute high-quality code to LangChain!
Edit the source of this page on GitHub.
Connect these docs programmatically to Claude, VSCode, and more via MCP for real-time answers.