litellm/CONTRIBUTING.md
Mateo Wang b8d79d1e0c
ci: drop mypy entirely, standardize type checking on basedpyright (#30648)
* ci: drop redundant mypy type-check gate, standardize on basedpyright

Type checking ran both mypy (via the pydantic.mypy plugin) and basedpyright.
pydantic v2 emits dataclass_transform, so basedpyright understands models
natively with no plugin, and its gated rules already cover what the mypy pass
caught (no-untyped-def, no-any-return, valid-type, import-not-found all map to
basedpyright equivalents). Running both meant two checkers, two budgets, and a
plugin only mypy could load.

This removes the mypy type-check gate: the lint-mypy/lint-mypy-budget-update
Makefile targets, the CI MyPy step, mypy-code-budget.json, the budget-ratchet
entry, and the vestigial [tool.mypy] pydantic plugin block (the gating pass used
litellm/mypy.ini, which never loaded the plugin). type_check_gate.py is
specialized to basedpyright since the mypy parsing path is now unused.

mypy stays a dev dependency because the Any-discipline gate
(scripts/check_any_discipline.py) imports it as a library to detect Any-typed
values; it is no longer run as a type checker.

* ci: remove the Any-discipline gate, rely on basedpyright's reportAny

The Any-discipline gate (scripts/check_any_discipline.py) was the last consumer
of mypy: it imported mypy as a library to detect values whose inferred type
contains Any, gated per-file against any-discipline-budget.json. basedpyright
already reports the same class of finding through reportAny/reportExplicitAny,
which are gated tree-wide in basedpyright-code-budget.json, so the separate gate
(and the mypy dependency behind it) is redundant.

Removes the gate end to end: check_any_discipline.py and its test, the
any-discipline CI job, the lint-any/lint-any-budget-update Makefile targets,
any-discipline-budget.json, litellm/mypy.ini, the .mypy_cache_any references,
and mypy from the dev dependencies. budget_ratchet_check.py drops the
any-discipline entry and the now-unused zero-floor mechanism (rewritten as a
comprehension). check_type_discipline.py drops the any-ok suppression token,
since # any-ok suppressed only the deleted gate; the 134 now-orphaned
# any-ok comments across 14 files are stripped (they never affected
basedpyright, which uses # pyright: ignore).

uv.lock is intentionally left untouched: uv still considers it consistent with
the mypy-removed pyproject (uv lock --check and uv sync --frozen both pass), and
a relock bumps 30+ unrelated packages because of the moving exclude-newer window.
A future intentional relock will prune the now-unreferenced mypy entry.

* build: relock to drop mypy from uv.lock

CI's uv 0.10.9 honors the repo's exclude-newer window and correctly flags the
lockfile as out of sync once mypy leaves pyproject; my earlier local uv 0.8.17
could not parse exclude-newer and silently passed --check. Relocking with the
pinned CI version removes only mypy and its transitive librt, with no other
version changes.
2026-06-17 09:42:00 -07:00

10 KiB

Contributing to LiteLLM

Thank you for your interest in contributing to LiteLLM! We welcome contributions of all kinds - from bug fixes and documentation improvements to new features and integrations.

Checklist before submitting a PR

Here are the core requirements for any PR submitted to LiteLLM:

  • Sign the Contributor License Agreement (CLA) - see details
  • Keep scope isolated - Your changes should address 1 specific problem at a time

Proxy (Backend) PRs

UI PRs

  • Ensure the UI builds successfully - npm run build
  • Ensure all UI unit tests pass - npm run test
  • Add tests for new components or logic - If you are adding a new component or new logic, add corresponding tests

Contributor License Agreement (CLA)

Before contributing code to LiteLLM, you must sign our Contributor License Agreement (CLA). This is a legal requirement for all contributions to be merged into the main repository.

Important: We strongly recommend reviewing and signing the CLA before starting work on your contribution to avoid any delays in the PR process.

Quick Start

1. Setup Your Local Development Environment

# Fork the repository on GitHub (click the Fork button at https://github.com/BerriAI/litellm)
# Then clone your fork locally
git clone https://github.com/YOUR_USERNAME/litellm.git
cd litellm

# Create a new branch for your feature (see "Commit and Branch Conventions" below)
git checkout -b feature/your-feature

# Install development dependencies
make install-dev

# Install git hooks that enforce commit + branch conventions (one-time, opt-in)
make install-hooks

# Verify your setup works
make help

That's it! Your local development environment is ready.

Commit and Branch Conventions

Commits follow Conventional Commits and branches follow Conventional Branches. Run make install-hooks once per clone to enable the local git hooks that enforce these — see the contributor docs for the full type list, examples, the protected-branch bypass list, and how to opt out.

2. Development Workflow

Here's the recommended workflow for making changes:

# Make your changes to the code
# ...

# Format your code (auto-fixes formatting issues)
make format

# Run all linting checks (matches CI exactly)
make lint

# Run unit tests to ensure nothing is broken
make test-unit

# Commit your changes (must follow Conventional Commits — see above)
git add .
git commit -m "feat(scope): your descriptive commit message"

# Push and create a PR (branch must follow Conventional Branches — see above)
git push origin feature/your-feature

Adding Testing

Adding at least 1 test is a hard requirement for all PRs.

Where to Add Tests

Add your tests to the tests/test_litellm/ directory.

  • This directory mirrors the structure of the litellm/ directory
  • Only add mocked tests - no real LLM API calls in this directory
  • For integration tests with real APIs, use the appropriate test directories

File Naming Convention

The tests/test_litellm/ directory follows the same structure as litellm/:

  • litellm/proxy/caching_routes.pytests/test_litellm/proxy/test_caching_routes.py
  • litellm/utils.pytests/test_litellm/test_utils.py

Example Test

import pytest
from litellm import completion

def test_your_feature():
    """Test your feature with a descriptive docstring."""
    # Arrange
    messages = [{"role": "user", "content": "Hello"}]
    
    # Act
    # Use mocked responses, not real API calls
    
    # Assert
    assert expected_result == actual_result

Running Tests and Checks

Running Unit Tests

Run all unit tests (uses parallel execution for speed):

make test-unit

If you're running broader test suites, proxy tests, or anything that touches PostgreSQL-backed fixtures/plugins, install the full local test environment first:

make install-test-deps

This syncs the locked test environment used across the repo, including psycopg v3 plus psycopg-binary (used by pytest-postgresql), psycopg2-binary (used by some proxy E2E tests), and a generated Prisma client for DB-backed proxy tests, so pytest startup matches CI without manual package installs.

Run specific test files:

uv run pytest tests/test_litellm/test_your_file.py -v

Running Linting and Formatting Checks

Run all linting checks (matches CI exactly):

make lint

Individual linting commands:

make format-check       # Check Black formatting
make lint-ruff          # Run Ruff linting
make lint-basedpyright  # Run basedpyright type checking
make check-circular-imports    # Check for circular imports
make check-import-safety       # Check import safety

Apply formatting (auto-fixes issues):

make format

Black formatting is enforced in CI. All PRs must pass the Black formatting check.

  • AI coding agents (Claude Code, Copilot, Cursor, etc.): AGENTS.md and CLAUDE.md instruct agents to run poetry run black . before committing.
  • VS Code users: Install the Black Formatter extension and enable format-on-save:
    {
      "[python]": {
        "editor.defaultFormatter": "ms-python.black-formatter",
        "editor.formatOnSave": true
      }
    }
    

CI Compatibility

To ensure your changes will pass CI, run the exact same checks locally:

# This runs the same checks as the GitHub workflows
make lint
make test-unit

For exact CI compatibility (pins OpenAI version like CI):

make install-dev-ci     # Installs exact CI dependencies

Available Make Commands

Run make help to see all available commands:

make help                       # Show all available commands
make install-dev               # Install development dependencies
make install-proxy-dev         # Install proxy development dependencies
make install-test-deps         # Install the full local test environment
make format                    # Apply Black code formatting
make format-check              # Check Black formatting (matches CI)
make lint                      # Run all linting checks
make test-unit                 # Run unit tests
make test-integration          # Run integration tests
make test-unit-helm            # Run Helm unit tests

Code Quality Standards

LiteLLM follows the Google Python Style Guide.

Our automated quality checks include:

  • Black for consistent code formatting
  • Ruff for linting and code quality
  • basedpyright for static type checking
  • Circular import detection
  • Import safety validation

All checks must pass before your PR can be merged.

Common Issues and Solutions

1. Linting Failures

If make lint fails:

  1. Formatting issues: Run make format to auto-fix
  2. Ruff issues: Check the output and fix manually
  3. basedpyright issues: Add proper type hints
  4. Circular imports: Refactor import dependencies
  5. Import safety: Fix any unprotected imports

2. Test Failures

If make test-unit fails:

  1. Check if you broke existing functionality
  2. Add tests for your new code
  3. Ensure tests use mocks, not real API calls
  4. Check test file naming conventions

3. Common Development Tips

  • Use type hints: basedpyright requires proper type annotations
  • Write descriptive commit messages: Help reviewers understand your changes
  • Keep PRs focused: One feature/fix per PR
  • Test edge cases: Don't just test the happy path
  • Update documentation: If you change APIs, update docs

Building and Running Locally

LiteLLM Proxy Server

To run the proxy server locally:

# Install proxy dependencies
make install-proxy-dev

# Start the proxy server
uv run litellm --config your_config.yaml

Docker Development

If you want to build the Docker image yourself:

# Build using the non-root Dockerfile
docker build -f docker/Dockerfile.non_root -t litellm_dev .

# Run with your config
docker run \
    -v $(pwd)/proxy_config.yaml:/app/config.yaml \
    -e LITELLM_MASTER_KEY="sk-1234" \
    -p 4000:4000 \
    litellm_dev \
    --config /app/config.yaml --detailed_debug

UI Development

1. Setup Your Local UI Development Environment

# Clone the repo (if you haven't already)
git clone https://github.com/YOUR_USERNAME/litellm.git
cd litellm

# Navigate to the UI dashboard directory
cd ui/litellm-dashboard

# Install dependencies
npm install

# Start the development server
npm run dev

2. Adding UI Tests

If you are adding a new component or new logic, you must add corresponding tests.

3. Running UI Unit Tests

npm run test

4. Building the UI

Ensure the UI builds successfully before submitting your PR:

npm run build

Submitting Your PR

  1. Push your branch: git push origin your-feature-branch
  2. Create a PR: Go to GitHub and create a pull request
  3. Fill out the PR template: Provide clear description of changes
  4. Wait for review: Maintainers will review and provide feedback
  5. Address feedback: Make requested changes and push updates
  6. Merge: Once approved, your PR will be merged!

Getting Help

If you need help:

What to Contribute

Looking for ideas? Check out:

Thank you for contributing to LiteLLM! 🚀