Litestar Dependency Injection

Use this skill for Provide, dependency maps, provider factories, request-scoped resources, and Dishka integration.

Code Style Rules

• 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>

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.

</workflow> <guardrails>

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.

</guardrails> <validation>

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.

</validation> <example>

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)}

</example>

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