SD.Next is a complex codebase with specific patterns and conventions. General app structure is:
- Python backend server
Uses Torch for model inference, FastAPI for API routes and Gradio for creation of UI components. - JavaScript/CSS frontend
venvfor Python environment management, activated withsource venv/bin/activate(Linux) orvenv\Scripts\activate(Windows).
venv MUST be activated before running any Python commands or scripts to ensure correct dependencies and environment variables.python3.10+.pyproject.tomlfor Python configuration, including linting and type checking settings.eslintconfigured for both core and UI code.pnpmfor managing JavaScript dependencies and scripts, with key commands defined inpackage.json.ruffandpylintfor Python linting, with configurations inpyproject.tomland executed viapnpm ruffandpnpm pylint.pre-commithooks which also check line-endings and other formatting issues, configured in.pre-commit-config.yaml.
- Entry/startup flow:
webui.sh->launch.py->webui.py-> modules undermodules/. - Install:
installer.pytakes care of installing dependencies and setting up the environment. - Core runtime state is centralized in
modules/shared.py(shared.opts, model state, backend/device state). - API/server routes are under
modules/api/. - UI codebase is split between base JS in
javascript/and actual UI inextensions-builtin/sdnext-modernui/. - Model and pipeline logic is split between
modules/sd_*andpipelines/. - Additional plug-ins live in
scripts/and are used only when specified. - Extensions live in
extensions-builtin/andextensions/and are loaded dynamically. - Tests and CLI scripts are under
test/andcli/, with some API smoke checks intest/full-test.sh.
- Prefer existing project patterns over strict generic style rules;
this codebase intentionally allows patterns often flagged in default linters such as allowing long lines, etc.
- Activate environment:
source venv/bin/activate(always ensure this is active when working with Python code). - Test startup:
python launch.py --test - Full startup:
python launch.py - Full lint sequence:
pnpm lint - Python checks individually:
pnpm ruff,pnpm pylint - JS checks:
pnpm eslintandpnpm eslint-ui
- Keep PR-ready changes targeted to
devbranch. - Use conventions from
CONTRIBUTING. - Do not include unrelated edits or submodule changes when preparing contributions.
- Use existing CLI/API tool patterns in
cli/andtest/when adding automation scripts. - Respect environment-driven behavior (
SD_*flags and options) instead of hardcoding platform/model assumptions. - For startup/init edits, preserve error handling and partial-failure tolerance in parallel scans and extension loading.
- Initialization order matters: startup paths in
launch.pyandwebui.pyare sensitive to import/load timing. - Shared mutable global state can create subtle regressions; prefer narrow, explicit changes.
- Device/backend-specific code paths (CUDA/ROCm/IPEX/DirectML/OpenVINO) should not assume one platform.
- Scripts and extension loading is dynamic; failures may appear only when specific extensions or models are present.