|
| 1 | +# API Providers Extraction: Architecture & Migration Checklist |
| 2 | + |
| 3 | +**Summary:** |
| 4 | +The goal of this migration is to extract all API provider logic from the main project into a standalone `api-providers` library. This makes the API layer easier to maintain, test, and reuse across projects. The process involves moving all provider code, updating imports, ensuring all dependencies are managed within the new package, and fully integrating the new library into the main project. |
| 5 | + |
| 6 | +--- |
| 7 | + |
| 8 | +## Progress Update (April 15, 2025) |
| 9 | + |
| 10 | +### What has been done: |
| 11 | + |
| 12 | +- The new `api-providers` package was created and all provider code was moved into it. |
| 13 | +- All internal imports in the new library and its test files are updated to use the new shared module path (`../../../shared` instead of `../../../shared/api`), reflecting the move of shared types/constants to an `index.ts` file. |
| 14 | +- The following test files have had their imports updated to the new path: |
| 15 | + - `bedrock.test.ts` |
| 16 | + - `deepseek.test.ts` |
| 17 | + - `glama.test.ts` |
| 18 | + - `lmstudio.test.ts` |
| 19 | + - `mistral.test.ts` |
| 20 | + - `ollama.test.ts` |
| 21 | +- Each file was updated to import from `../../../shared` (directory) rather than `../../../shared/api` (file). |
| 22 | +- All test and source file imports from `../../../shared/api` to `../../../shared` are now complete. |
| 23 | +- All required provider SDKs and dependencies have been added to `packages/api-providers/package.json`. |
| 24 | +- The main program (including `src/core/Cline.ts` and `src/core/webview/ClineProvider.ts`) now uses the new `api-providers` package for all API logic. The import in `ClineProvider.ts` was updated from the old local API to the new package. |
| 25 | +- The integration step is complete: all usage of the old API layer has been replaced with imports from the new package. |
| 26 | +- Provider SDK dependencies have been removed from the main project's `package.json`. |
| 27 | +- The build and type check process now completes successfully with the new library structure, after updating TypeScript module resolution and ensuring all dependencies are available at the root. |
| 28 | + |
| 29 | +### What is next: |
| 30 | + |
| 31 | +- [x] Remove provider SDK dependencies from the main project's `package.json` if no longer needed. |
| 32 | +- [x] Re-run the build to confirm that the package and the main project compile successfully using the new library structure. |
| 33 | +- [x] If the build passes, proceed to run all tests to ensure nothing is broken. |
| 34 | +- [x] Once all tests pass, continue with the remaining checklist steps (dependency cleanup, documentation, etc.). |
| 35 | + |
| 36 | +--- |
| 37 | + |
| 38 | +## How the API Provider System Works |
| 39 | + |
| 40 | +[...unchanged, see previous version...] |
| 41 | + |
| 42 | +--- |
| 43 | + |
| 44 | +## Checklist: Extract API Providers into a Standalone Library |
| 45 | + |
| 46 | +Use this checklist to guide the process of moving the API provider layer into its own package/library. |
| 47 | + |
| 48 | +--- |
| 49 | + |
| 50 | +### Preparation |
| 51 | + |
| 52 | +- [x] Review the current API provider structure in `src/api/` and `src/api/providers/` |
| 53 | +- [x] Identify all shared types/interfaces needed from `src/shared/api.ts` |
| 54 | +- [x] List all provider-specific dependencies (SDKs, utilities) |
| 55 | + |
| 56 | +--- |
| 57 | + |
| 58 | +### 1. Create the New Package |
| 59 | + |
| 60 | +- [x] Create a new directory for the library (e.g., `packages/api-providers` or a new repo) |
| 61 | +- [x] Initialize the package with `package.json`, `tsconfig.json`, etc. |
| 62 | +- [x] Set up the directory structure (`src/`, `__tests__/`, etc.) |
| 63 | + |
| 64 | +--- |
| 65 | + |
| 66 | +### 2. Move Code |
| 67 | + |
| 68 | +- [x] Move all files from `src/api/` (including `providers/`, `transform/`, etc.) into the new package's `src/` |
| 69 | +- [x] Move required shared types from `src/shared/api.ts` into the new package (or a shared package if needed) |
| 70 | +- [x] Move provider-specific dependencies (from `src/utils/`, `src/shared/`, etc.) into the new package |
| 71 | +- [x] Exclude non-essential extension/UI integration files (e.g., `human-relay.ts`, `ExtensionMessage.ts`, etc.) to keep the library minimal and maintainable |
| 72 | + |
| 73 | +--- |
| 74 | + |
| 75 | +### 3. Update Imports |
| 76 | + |
| 77 | +- [x] Update all internal imports in the new package to use relative paths (preserved by copying directory structure) |
| 78 | +- [x] Remove or update imports in the API code that referenced excluded files (e.g., remove `HumanRelayHandler` from `index.ts`) |
| 79 | +- [x] Update all test and source file imports from `../../../shared/api` to `../../../shared` |
| 80 | + |
| 81 | +--- |
| 82 | + |
| 83 | +### 4. Manage Dependencies |
| 84 | + |
| 85 | +- [x] Add all provider SDKs and dependencies to the new package's `package.json` |
| 86 | +- [x] Remove these dependencies from the main project's `package.json` if no longer needed |
| 87 | +- [x] Ensure all dependencies required by the library are available in the root node_modules for build tools |
| 88 | + |
| 89 | +--- |
| 90 | + |
| 91 | +### 5. Testing |
| 92 | + |
| 93 | +- [x] Ensure all provider tests run successfully in the new package |
| 94 | +- [x] Mock or adapt any project-specific dependencies in tests |
| 95 | +- [x] Run integration tests in the main project after switching to the new package |
| 96 | + |
| 97 | +--- |
| 98 | + |
| 99 | +### 6. Build and Publish |
| 100 | + |
| 101 | +- [x] Set up build scripts (e.g., using `tsc` or `esbuild`) |
| 102 | +- [x] Build the package and verify output (package now compiles cleanly) |
| 103 | +- [ ] Optionally publish the package to a registry (private or public) |
| 104 | + |
| 105 | +--- |
| 106 | + |
| 107 | +### 7. Integrate with Main Project |
| 108 | + |
| 109 | +- [x] Replace all usage of the old API layer in the main project with imports from the new package |
| 110 | +- [x] Test the integration thoroughly to ensure everything works as expected |
| 111 | +- [x] Ensure the new package is built automatically as part of the main project build process |
| 112 | + |
| 113 | +--- |
| 114 | + |
| 115 | +### 8. Optional Improvements |
| 116 | + |
| 117 | +- [ ] Expose only the public API (interfaces, factory, types) from the package entry point |
| 118 | +- [ ] Add documentation and usage examples to the new package's README |
| 119 | +- [ ] Consider open-sourcing the package if it is generic and reusable |
| 120 | + |
| 121 | +--- |
| 122 | + |
| 123 | +### 9. Final Review |
| 124 | + |
| 125 | +- [x] Confirm all references to the old API layer are removed from the main project |
| 126 | +- [x] Ensure all tests (unit and integration) pass in both the library and the main project |
| 127 | +- [x] Review for any remaining project-specific coupling and refactor as needed |
| 128 | + |
| 129 | +--- |
| 130 | + |
| 131 | +**Notes:** |
| 132 | + |
| 133 | +- Non-essential files (VSCode extension UI, integration, and human-relay logic) were excluded from the package to keep the library focused and maintainable. |
| 134 | +- All core API provider logic and direct dependencies are included, preserving original file structure for easy syncing with the main fork. |
| 135 | + |
| 136 | +**References:** |
| 137 | + |
| 138 | +- Main API entry: `src/api/index.ts` |
| 139 | +- Provider implementations: `src/api/providers/` |
| 140 | +- Usage points: `src/core/Cline.ts`, `src/core/webview/ClineProvider.ts` |
| 141 | +- Shared types: `src/shared/api.ts` |
0 commit comments