litestar-di

Litestar Dependency Injection

Use this skill for Provide, NamedDependency / SkipValidation (Litestar ≥ 2.23), dependency maps, provider factories, request-scoped resources, and Dishka integration.

Code Style Rules

• Prefer NamedDependency[T] and SkipValidation[T] (≥ 2.23) over Annotated[T, Dependency()] / Dependency(skip_validation=True); params.Dependency is deprecated (removed in 3.0).
• Use Litestar dependency maps for simple and medium apps.
• Use Dishka when the project needs explicit scopes and provider modules.
• Keep provider names stable and descriptive.
• Do not open request-scoped resources at import time.

Quick Reference

• DI patterns: di.md
• Pair with litestar-data-services for service providers.
• Pair with litestar-settings for settings injection.

Workflow

1. Identify whether the dependency is app, request, transaction, or function scoped.
2. Choose built-in dependency maps or the existing DI framework.
3. Register providers at the narrowest useful scope.
4. Inject dependencies by name or type according to the chosen stack.

Guardrails

• Do not introduce Dishka for one or two simple providers.
• Do not mix dependency naming conventions in one app.
• Do not keep database sessions or clients as global mutable state.
• Do not hide business logic inside providers.

Validation Checkpoint

• Dependency scope is explicit.
• Providers are async when they manage async resources.
• Tests can override providers cleanly.
• Provider wiring matches the app's existing DI style.

Example

from litestar.di import Provide

async def provide_user_service(db_session: AsyncSession) -> UserService:
    return UserService(session=db_session)

dependencies = {"users_service": Provide(provide_user_service)}

References Index

• di.md

Official References

• https://docs.litestar.dev/ - Litestar documentation
• https://docs.litestar.dev/latest/reference/ - Litestar API reference

Shared Styleguide Baseline

• General
• Python
• Litestar