* 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>
* 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
* Move the generated files for the host bridge into the 'src/generated' directory
Move the generated index.ts and methods.ts files for the host bridge into the 'src/generated' directory
I'm doing this because when all the generated files are one in location its a) easier to see from the import statement that the code is generated, b) it's easier to change the package(s) of the generated files, and c) easier to reset/clean the build state.
* Update import path
* Move the hostbridge handlers in the a hostbridge packge.
Move the hostbridge handlers out of the top level of the vscode package into their own subpackage.
I have to move all the vscode specific code into the `hosts/vscode` package, and I want the hostbridge handlers to be grouped together, not mixed in with things like the VscodeDiffViewProvider, VscodeWebviewProvider etc.
* Move the generated files for the host bridge into the 'src/generated' directory
Move the generated index.ts and methods.ts files for the host bridge into the 'src/generated' directory
I'm doing this because when all the generated files are one in location its a) easier to see from the import statement that the code is generated, b) it's easier to change the package(s) of the generated files, and c) easier to reset/clean the build state.
* Update import path
Ara