32bdd004bd
Cut the default "Virtual Keys" landing (?page=api-keys) over to a path route at (dashboard)/api-keys. The dashboard is extracted into a shared ApiKeysDashboard component used by both the new route and the index's inline render, so there's no duplication. Adding the MIGRATED_PAGES entry repoints the sidebar item and redirects ?page=api-keys to /ui/api-keys. The index is the post-login landing and still hosts the legacy switch for the not-yet-migrated pages (models, pass-through, usage) plus the invitation flow, so it stays. The auto-redirect now fires only for an explicit ?page= param, leaving the bare /ui/ landing to render inline; this keeps the return-URL handling and the invitation_id flow (both of which run at the bare landing) intact, where a blanket redirect would have dropped them. The new route uses useAuthorized for the login gate, matching every other migrated route. |
||
|---|---|---|
| .. | ||
| migratedPages.spec.ts | ||
| README.md | ||
App Router migration smoke
A growing E2E smoke for pages migrated from the legacy ?page= switch to App
Router path routes. For each migrated page it clicks the page's sidebar link, checks
the URL is the path route and the page renders, reloads it, then clicks off to a
legacy page and back to confirm navigation still works. It runs in two situations:
the default mount and a non-root SERVER_ROOT_PATH mount.
Adding a page
When a page's migration merges, add its route segment to
e2e_tests/fixtures/migratedPages.ts (keep it in lockstep with MIGRATED_PAGES
in src/utils/migratedPages.ts). Both suites pick it up automatically.
Running
Build the UI into the proxy and start the proxy first (the suite runs against
http://localhost:4000).
Default mount:
npm run e2e:migration
Non-root mount (build and boot the proxy with the same root path, e.g. /litellm):
SERVER_ROOT_PATH=/litellm npm run e2e:migration:root
globalSetup logs in once per role; the admin storage state is reused for these
tests. Under a non-root mount it logs in at ${SERVER_ROOT_PATH}/ui/login.