cca1b8f06e
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
2.1 KiB
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