litellm/ui/litellm-dashboard/CLAUDE.md
ryan-crabbe-berri cca1b8f06e ci: commit openapi.json and gate it with a verify-codegen script
Adds the proxy's OpenAPI spec to the repo as openapi.json so diff tooling has a
committed baseline, and replaces the inline drift check with the update/verify
script pair Kubernetes uses so the same command runs locally and in CI.

- scripts/update-codegen.sh is the single writer for generated artifacts
- scripts/verify-codegen.sh runs it and fails on any git status change
- the sync job now runs on every PR instead of a path filter, so routes defined
  outside litellm/proxy (enterprise/**) can no longer land a stale spec
- git status --porcelain replaces git diff, which was blind to untracked files
2026-08-07 15:53:16 -07:00

11 lines
2.1 KiB
Markdown

Never put LiteLLM tokens or API keys in `localStorage`. `localStorage` survives browser close. Prefer `httpOnly` cookies, or `sessionStorage` at most, understanding that any web storage is readable by injected scripts (XSS), and only httpOnly cookies are not
When you fix lint violations that are grandfathered in `eslint-suppressions.json`, run `eslint . --prune-suppressions` and commit the updated baseline so the gate ratchets down instead of leaving a stale suppression
`openapi.json` at the repo root and `src/lib/http/schema.d.ts` are both generated from the proxy's FastAPI app; never hand-edit either. After changing any backend route or response model, run `scripts/update-codegen.sh` from the repo root and commit both files. `scripts/verify-codegen.sh` is the same generator plus a `git status` check, and it runs on every PR as `Check UI API Types Sync`, so you can reproduce a CI failure locally with it
Tests come in three tiers, named by the standard definitions. `Foo.test.tsx` is a unit test: one module, collaborators replaced by doubles, no multi-component tree, and it should run in milliseconds. `Foo.integration.test.tsx` renders a real component tree with real children and only stubs the network boundary; it costs seconds per case, so it earns its place by proving wiring that a unit test cannot reach. Browser-level tests live in `tests/e2e/ui/` as Playwright specs against a live proxy
When a component holds logic worth asserting, extract the logic and unit-test it there rather than driving it through a render. `CreateMCPServer` is the worked example: its payload building lives in `createServerPayload.ts` with 46 unit tests that run in single-digit milliseconds, while `CreateMCPServer.integration.test.tsx` keeps only the cases that prove a form field reaches the right payload key. A test that renders a whole modal to assert the shape of one object belongs in the first category, not the second
Most of the suite predates this split and is not yet classified, so an unsuffixed `*.test.tsx` is not evidence that a file is really a unit test. Classify what you touch