* chore: add CLI type checking and caching to ci workflow
- Added a new cache step for CLI dependencies in the GitHub Actions test workflow to improve build performance.
- Included a step to install CLI dependencies using `npm ci`.
- Updated the `ci:check-all` script in `package.json` to include CLI type checking.
- Added a `cli:typecheck` script to handle type checking within the CLI directory.
* Fix type and import issues for cli
* Includes CI tests in test workflow
* use npx npm-run-all
* update ci:check-all
* ci: skip npm ci steps on cache hit in test workflow
Update the test workflow to conditionally run npm installation steps only when a cache hit is not found. This optimization reduces CI execution time by avoiding redundant dependency installations when the node_modules are already restored from cache.
* ci: update cache keys and add dependency verification in test workflow
Updated the cache keys for root, webview-ui, cli, and testing-platform dependencies by adding a version prefix (v1). This ensures a clean cache state and helps avoid potential corruption or mismatch issues.
Additionally, added a verification step in the test job to log cache hit status and check for the presence of key dependencies like biome and globby. This helps diagnose issues where the cache might be restored but dependencies are not correctly available for subsequent steps.
* update Verify and fix root dependencies
* fix type check script
* add isSettingsKey check
* update settingskey set
* apply feedback
* npx
* feat: flashing dot for streaming chat messages in CI (#9054)
Introduce an ink-spinner to the DotRow component to provide visual feedback when messages are being streamed. This improves the CLI user experience by clearly indicating that a tool call or message is currently in progress.
- Add `flashing` prop to `DotRow` component
- Replace static dot with `toggle8` spinner when `flashing` is true
- Update `ChatMessage` to pass `flashing` state based on `isStreaming` and `partial` message properties
Co-authored-by: Saoud Rizwan <7799382+saoudrizwan@users.noreply.github.com>
* ci: simplify dependency caching using built-in npm cache
Replace manual actions/cache steps with setup-node's built-in npm caching feature across all workflow jobs. This change:
- Removes redundant cache action steps for root, webview-ui, cli, and testing-platform dependencies
- Uses setup-node's native `cache: 'npm'` option with `cache-dependency-path` to handle multiple package-lock.json files
- Eliminates conditional installation steps based on cache hits
- Reduces workflow complexity and maintenance overhead while maintaining caching functionality
The built-in caching provides the same performance benefits with less configuration and better integration with the Node.js setup action.
---------
Co-authored-by: Saoud Rizwan <7799382+saoudrizwan@users.noreply.github.com>
* Enable biome rules: noUnusedVariables, noUnusedFunctionParameters, noUnusedImports
* Apply new rules with format
* remove unused currentReplaceContent
* update nextTerminalId
* fix all format issues
* update biome config
* add back applyContextOptimizations and killAllChromeBrowsers
* Add a check to the proto scripts to warn about using int64 types.
Javascript cannot represent the full range of int64. So, when the protos are deserialized from JSON int64's are converted to strings. The typescript code is expecting a number and not a string, and this causes errors.
This was noticed before now because in the vscode protobus and hostbridge, the proto messages are not serialized and deserialized, they are just passed around as JS objects.
However, in IntelliJ the protos are serialized when they are sent through the ProtoBus. When the response messages contains and int64, it is deserialized to a string instead of a number for safety. This is causes parts of Cline to fail in IntelliJ, e.g. the task history view won't load because `Task.getTotalTasksSize()` returns a string when it is expecting a number.
* Make checkProtos shorter
* Update scripts/build-proto.mjs
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* Update scripts/build-proto.mjs
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* Update scripts/build-proto.mjs
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* Fix typo
* Fix typo
* Fix bad merge
---------
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* Remove compiled files that were committed by mistake
* Don't JSON encode the grpc message request.
The original grpc-client-base.ts encoded the request message using
```
function encodeRequest(request: any): any {
if (request === null || request === undefined) {
return {}
} else if (typeof request.toJSON === "function") {
return request.toJSON()
} else if (typeof request === "object") {
return { ...request }
} else {
return { value: request }
}
```
But the request object don't have a .toJSON method, so it was not actually converting them
to JSON properly.
Don't JSON encode request to keeo the same behaviour as before.
* Update gitignore
* fix: Generate type-safe code for the Vscode Protobus service
This commit establishes a fully type-safe ProtoBus system by fixing the streaming
response handler type definitions and completing the protobuf-driven architecture.
Key improvements:
• **Complete type safety**: ProtoBus is now completely type-safe with compile-time
validation of all gRPC service definitions, request/response types, and handler
signatures
• **Simplified message creation**: No longer need to manually call `Message.create({...})`
- the generated code handles message instantiation automatically
• **Automated proto parsing**: Eliminated manual parsing of proto files - the build
system now automatically generates TypeScript definitions from protobuf schemas
• **Proto files as source of truth**: Service names, method names, and message types
are now definitively controlled by the proto files, ensuring consistency across
the entire codebase
• **Handler type checking**: ProtoBus handlers are fully type-checked including:
- Request and response type validation
- Handler method name verification against proto definitions
- Streaming vs unary handler signature enforcement
This establishes a robust, type-safe foundation for all gRPC communication between
the extension host and webview components.
* Remove commented out code in script
* Just call handlers directly
