mirror of
https://github.com/CherryHQ/cherry-studio.git
synced 2026-07-03 12:27:41 +08:00
### What this PR does Before this PR: - v2 migration did not include provider/model data migration from legacy `llm` state. - Provider/model data APIs and handlers were incomplete. - `@cherrystudio/provider-registry` (formerly provider-catalog) package was not integrated into the data layer. After this PR: - Add provider/model migration path (`ProviderModelMigrator` + mappings) and register it in v2 migrator flow. - Add `@cherrystudio/provider-registry` package with JSON-based registry data, Zod-validated schemas, and lifecycle-managed `ProviderRegistryService`. - Complete provider/model schemas, services, handlers, shared API schemas/types, and model merger utility. - Complete provider API endpoints (`registry-models`, `auth-config`, `api-keys`) aligned with lifecycle DI patterns. **Note:** This PR is intentionally scoped to backend/data-layer only. Renderer consumer migration will be submitted in a separate PR to maintain domain separation. Fixes # N/A ### Why we need it and why it was done in this way The following tradeoffs were made: - Kept migration and data API implementation within current v2 architecture (handler -> service -> db schema) instead of adding temporary compatibility layers. - Replaced protobuf toolchain with JSON + Zod validation for simpler data pipeline and better debuggability. - Converted all numeric enums to string-valued `as-const` objects (EndpointType, ModelCapability, Modality, etc.) for runtime debuggability. - Unified separate `baseUrls`, `modelsApiUrls`, `reasoningFormatTypes` fields into a single `endpointConfigs` map keyed by EndpointType. The following alternatives were considered: - Keep protobuf-based registry data; rejected due to complexity of proto toolchain and poor debuggability of binary data. - Include renderer consumer migration in same PR; deferred to separate PR for cleaner domain boundaries. Links to places where the discussion took place: - Original combined PR: #14034 ### Breaking changes None. ### Special notes for your reviewer - This is a backend-only extraction from #14034, which contained both backend and renderer consumer code. The renderer migration will follow in a separate PR. - Please focus review on migration flow (`ProviderModelMigrator`), provider/model service contracts, and the registry package design. - The `@cherrystudio/provider-registry` package was renamed from `provider-catalog` and uses JSON data files instead of protobuf. ### Checklist - [x] PR: The PR description is expressive enough and will help future contributors - [x] Code: Write code that humans can understand and Keep it simple - [x] Refactor: You have left the code cleaner than you found it (Boy Scout Rule) - [ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required - [ ] Documentation: Not required (internal data layer, no user-facing changes) - [x] Self-review: I have reviewed my own code ### Release note ```release-note NONE ``` --------- Signed-off-by: jidan745le <420511176@qq.com> Signed-off-by: suyao <sy20010504@gmail.com> Co-authored-by: suyao <sy20010504@gmail.com> Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: fullex <106392080+0xfullex@users.noreply.github.com>
24 lines
515 B
JSON
24 lines
515 B
JSON
{
|
|
"tsDecorders": "legacy",
|
|
"files": [],
|
|
"references": [
|
|
{
|
|
"path": "./tsconfig.node.json"
|
|
},
|
|
{
|
|
"path": "./tsconfig.web.json"
|
|
}
|
|
],
|
|
"compilerOptions": {
|
|
"experimentalDecorators": true,
|
|
"emitDecoratorMetadata": true,
|
|
"useDefineForClassFields": true,
|
|
"baseUrl": ".",
|
|
"paths": {
|
|
"@renderer/*": ["src/renderer/src/*"],
|
|
"@shared/*": ["packages/shared/*"],
|
|
"@cherrystudio/provider-registry": ["packages/provider-registry/src/index.ts"]
|
|
}
|
|
}
|
|
}
|