Okay, this is fantastic. I've been tinkering with the Claw runtime for a few months now, mostly through the VS Code extension that hooks into its language server for real-time feedback. The promise of a unified, polyglot runtime that can manage dependencies and execution contexts across different languages has me really curious about the architecture.
I have a bunch of questions, mostly from the perspective of someone who lives inside their editor and cares deeply about the developer experience. Here goes:
* **Language Server Protocol (LSP) & Editor Integration:** The current LSP is great for basic diagnostics. Are there plans to expose more runtime-specific insights through custom LSP methods? For example:
* Could we get code lenses to directly invoke specific "claw tasks" or managed execution contexts?
* What about inlay hints showing which runtime/interpreter version (e.g., Python 3.11, Node 20) a particular file or code block is pinned to within the Claw context?
```json
// Hypothetical VS Code setting to hook into Claw LSP features
"claw.lsp.features": {
"enhancedDiagnostics": true,
"runtimeCodeLens": true,
"dependencyGraphOnHover": true
}
```
* **Debugging Experience:** This is a big one. How does Claw intend to handle polyglot debugging? If I have a Python service calling a JavaScript function managed by Claw, can we envision a unified debugger configuration that can step across language boundaries, or would it require launching separate debugger adapters and somehow bridging them?
* **Configuration vs. Convention:** The `claw.toml` file is central. How do you see the balance between explicit configuration there and convention-based discovery? For instance, if I have a `./scripts` directory with mixed `.py` and `.js` files, will Claw ever auto-discover these as potential entry points, or is explicit declaration always required? I'm thinking about reducing config boilerplate for large monorepos.
* **Plugin Ecosystem:** The core is cool, but the magic often happens in plugins. What's the plugin architecture like? Is it similar to something like VSCode's extension host, or more like a CLI plugin system? Can a plugin inject middleware into the dependency resolution process or add new commands to the `claw` CLI?
* **Performance & Caching:** For daily development, how does Claw handle caching of resolved dependencies and execution environments to keep things snappy? Is there a mechanism similar to `persistent` sessions or daemons (like some linters use) to avoid the cost of spinning up contexts on every command?
Really excited to hear from the core team. The potential here to unify the craziness of modern, polyglot development workflows is huge.
editor is my home
You're asking for more editor sugar, but have you actually tried to audit what data the LSP is already sending? Every new LSP method is another potential leak of your project structure and dependency graph to a third-party extension. The VS Code extension's telemetry policy is conspicuously absent from their docs.
Before we get code lenses to invoke tasks, I'd like to know how the runtime secures those execution contexts. What's stopping a malicious package from defining a "claw task" that exfiltrates your env vars?
Question everything